diff --git a/docs/src/main/asciidoc/getting-started-reactive.adoc b/docs/src/main/asciidoc/getting-started-reactive.adoc index 1330c96deb259..5387908258002 100644 --- a/docs/src/main/asciidoc/getting-started-reactive.adoc +++ b/docs/src/main/asciidoc/getting-started-reactive.adoc @@ -56,7 +56,7 @@ Indeed, to handle multiple concurrent requests, you need multiple threads; and s In addition, these threads are blocked as soon as your code interacts with remote services. So, it leads to inefficient usage of the resources, as you may need more threads, and each thread, as they are mapped to OS threads, has a cost in terms of memory and CPU. -image::blocking-threads.png[alt=Imperative Execution Model and Worker Threads] +image::blocking-threads.png[alt=Imperative Execution Model and Worker Threads,width=80%] On the other side, the reactive model relies on non-blocking I/Os and a different execution model. Non-blocking I/O provides an efficient way to deal with concurrent I/O. @@ -65,7 +65,7 @@ With such a model, request processing is not delegated to a worker thread but us It also improves the concurrency as it removes the constraint on the number of threads. Finally, it also improves response time as it reduces the number of thread switches. -image::reactive-thread.png[alt=Reactive Execution Model and I/O Threads] +image::reactive-thread.png[alt=Reactive Execution Model and I/O Threads,width=80%] == From sequential to continuation style diff --git a/docs/src/main/asciidoc/images/blocking-threads.png b/docs/src/main/asciidoc/images/blocking-threads.png index c1fcc7f2ca968..474f3648898b7 100644 Binary files a/docs/src/main/asciidoc/images/blocking-threads.png and b/docs/src/main/asciidoc/images/blocking-threads.png differ diff --git a/docs/src/main/asciidoc/images/proactor-pattern.png b/docs/src/main/asciidoc/images/proactor-pattern.png index ec0ae6f1fc52c..2218c588da386 100644 Binary files a/docs/src/main/asciidoc/images/proactor-pattern.png and b/docs/src/main/asciidoc/images/proactor-pattern.png differ diff --git a/docs/src/main/asciidoc/images/quarkus-reactive-core.png b/docs/src/main/asciidoc/images/quarkus-reactive-core.png index ae962b734e573..59dcae49af055 100644 Binary files a/docs/src/main/asciidoc/images/quarkus-reactive-core.png and b/docs/src/main/asciidoc/images/quarkus-reactive-core.png differ diff --git a/docs/src/main/asciidoc/images/reactive-systems.png b/docs/src/main/asciidoc/images/reactive-systems.png index 8469340aad592..45c796a995b67 100644 Binary files a/docs/src/main/asciidoc/images/reactive-systems.png and b/docs/src/main/asciidoc/images/reactive-systems.png differ diff --git a/docs/src/main/asciidoc/images/reactive-thread.png b/docs/src/main/asciidoc/images/reactive-thread.png index b6a29bc4b0739..f8fd7616195b3 100644 Binary files a/docs/src/main/asciidoc/images/reactive-thread.png and b/docs/src/main/asciidoc/images/reactive-thread.png differ diff --git a/docs/src/main/asciidoc/mutiny-primer.adoc b/docs/src/main/asciidoc/mutiny-primer.adoc index 9578522e96178..8c53d03ed0d06 100644 --- a/docs/src/main/asciidoc/mutiny-primer.adoc +++ b/docs/src/main/asciidoc/mutiny-primer.adoc @@ -70,7 +70,7 @@ Remember, you must never block these threads, and the model would collapse if yo So, you can't use blocking I/O. Instead, you need to schedule the I/O operation and pass a continuation. -image::reactive-thread.png[alt=Reactive Execution Model and I/O Threads] +image::reactive-thread.png[alt=Reactive Execution Model and I/O Threads,width=80%] The Mutiny event-driven paradigm is tailored for this. When the I/O operation completes successfully, the Uni that represents it emits an item event. diff --git a/docs/src/main/asciidoc/quarkus-reactive-architecture.adoc b/docs/src/main/asciidoc/quarkus-reactive-architecture.adoc index 98bf36007756a..621bf451cc99f 100644 --- a/docs/src/main/asciidoc/quarkus-reactive-architecture.adoc +++ b/docs/src/main/asciidoc/quarkus-reactive-architecture.adoc @@ -29,7 +29,7 @@ The https://www.reactivemanifesto.org/[Reactive Manifesto] characterizes _Reacti 3. Resilient - they handle failures gracefully 4. Asynchronous message passing - the component of a reactive system interact using messages -image::reactive-systems.png[alt=Reactive Systems Pillars] +image::reactive-systems.png[alt=Reactive Systems Pillars,width=80%] In addition to this, the https://principles.reactive.foundation/[Reactive Principles white paper] lists a set of rules and patterns to help the construction of reactive systems. @@ -69,7 +69,7 @@ As a result, Quarkus applications allow for higher concurrency, use less memory, Under the hood, Quarkus has a reactive engine. This engine, powered by Eclipse Vert.x and Netty, handles the non-blocking I/O interactions. -image::quarkus-reactive-core.png[Quarkus Reactive Core] +image::quarkus-reactive-core.png[Quarkus Reactive Core,width=80%] Quarkus extensions and the application code can use this engine to orchestrate I/O interactions, interact with databases, send and receive messages, and so on. @@ -89,7 +89,7 @@ The size of this pool constrains the concurrency of the application. In addition, each thread has a cost in terms of memory and CPU. Large thread pools result in greedy applications. -image::blocking-threads.png[alt=Imperative Execution Model and Worker Threads] +image::blocking-threads.png[alt=Imperative Execution Model and Worker Threads,width=80%] As we have seen above, non-blocking I/O avoids that problem. A few threads can handle many concurrent I/O. @@ -98,7 +98,7 @@ Because there are only a few of them, you need to use them wisely. When the request processing needs to call a remote service, you can't block the thread anymore. You schedule the I/O and pass a continuation, i.e., the code to execute once the I/O completes. -image::reactive-thread.png[alt=Reactive Execution Model and I/O Threads] +image::reactive-thread.png[alt=Reactive Execution Model and I/O Threads,width=80%] This model is much more efficient, but we need a way to write code to express these continuations. @@ -139,7 +139,7 @@ It means that you can write traditional blocking applications on Quarkus. But how do you avoid blocking the I/O threads? Quarkus implements a https://en.wikipedia.org/wiki/Proactor_pattern[proactor pattern] that switches to worker thread when needed. -image::proactor-pattern.png[The proactor pattern in Quarkus] +image::proactor-pattern.png[The proactor pattern in Quarkus,width=80%] Thanks to hints in your code (such as the `@Blocking` and `@NonBlocking` annotations), Quarkus extensions can decide when the application logic is blocking or non-blocking. If we go back to the HTTP endpoint example from above, the HTTP request is always received on an I/O thread.