Merge pull request quarkusio#17732 from cescoffier/fix-reactive-pictures

Update reactive picture to match with the web site background
geoand · Jun 7, 2021 · 505876b · 505876b
2 parents 11607b6 + e484c05
commit 505876b
Show file tree

Hide file tree

Showing 8 changed files with 8 additions and 8 deletions.
diff --git 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
diff --git a/docs/src/main/asciidoc/images/proactor-pattern.png b/docs/src/main/asciidoc/images/proactor-pattern.png
diff --git a/docs/src/main/asciidoc/images/quarkus-reactive-core.png b/docs/src/main/asciidoc/images/quarkus-reactive-core.png
diff --git a/docs/src/main/asciidoc/images/reactive-systems.png b/docs/src/main/asciidoc/images/reactive-systems.png
diff --git a/docs/src/main/asciidoc/images/reactive-thread.png b/docs/src/main/asciidoc/images/reactive-thread.png
diff --git 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
@@ -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.