This document provides an overview of reactive programming concepts and technologies. It defines reactive programming as using asynchronous and non-blocking code to build responsive and resilient applications. It discusses reactive concepts like the event loop, back pressure, and overflow management. Frameworks like Vert.x and libraries like SmallRye Mutiny that support reactive programming on the JVM are also introduced. The key advantages of reactive programming are supporting more concurrent connections using fewer threads and efficiently processing asynchronous data streams.

1. Edgar Domingues
May 2021
+

2. 01
02
03
Agenda
What is Reactive
2
Why be Reactive
Code

3. What is Reactive

4. Traditional Multi-threading
4

5. Reactive Event Loop
5

6. Reactive Landscape
6
The Reactive Manifesto
Reactive Streams
“a standard for asynchronous stream processing with non-blocking back pressure”
● Responsive
● Resilient
● Elastic
● Message Driven
Java Flow API

7. Back-Pressure
7

8. Overflow management
// Set the max size to 10 and fail if reached
@OnOverflow(value = OnOverflow.Strategy.BUFFER, bufferSize = 10)
@Inject @Channel("channel") Emitter<String> emitterWithBuffer;
// [DANGER ZONE] no limit
@OnOverflow(OnOverflow.Strategy.UNBOUNDED_BUFFER)
@Inject @Channel("channel") Emitter<String> danger;
// Drop the new messages if the size is reached
@OnOverflow(OnOverflow.Strategy.DROP)
@Inject @Channel("channel") Emitter<String> dropping;
// Drop the previously sent messages if the size is reached
@OnOverflow(OnOverflow.Strategy.LATEST)
@Inject @Channel("channel") Emitter<String> dropOldMessages;
8
https://smallrye.io/smallrye-reactive-messaging/smallrye-reactive-messaging/3.2/emitter/emitter.html#emitter-overflow

9. Vert.x
“Eclipse Vert.x is a tool-kit for building reactive applications on the JVM.”
• Bare API: for advanced usage or if you have existing Vert.x code you want to
reuse in your Quarkus application
• Mutiny API: Mutiny is an event-driven reactive programming API. It uses 2
types: Uni and Multi. This is the recommended API.
Multi-Reactor Pattern: multiple event loops, based on available cores
(unlike Node.js it can scale)
9

10. Mutiny!
SmallRye Mutiny is a event-driven reactive programming library.
Vert.x ⇒ Mutiny API:
• io.vertx package ⇒ io.vertx.mutiny package
• Asynchronous methods ⇒ method returning a Uni<T>
• ReadStreams<T> ⇒ can be consumed as Multi<T>
• WriteStreams<T> ⇒ can be consumed as Reactive Streams Subscriber<T>
It also adapts the Vert.x back pressure protocol to Reactive Streams, as Mutiny implements
Reactive Streams.
10

11. Why be Reactive

12. • More concurrent connections with less threads.
‒ Creating a new thread takes a few milliseconds and 1MB of memory.
• Processing asynchronous data streams.
• Users expect fast response times and low latency.
Why be Reactive?
12
“When using Quarkus Reactive Routes [...] purely on the IO thread, we observed 2.6x times the
requests/sec and 30% less memory usage (RSS than running with Quarkus RESTEasy (which mixes
IO thread and worker thread).”

13. When not to be Reactive
• Code with multiple blocking I/O requests, that is frequently context switching
between main and worker threads instead of being handled by a single thread.
• CPU intensive processing or parallelizable algorithms that don’t need to be
responsive.
13

14. The Golden Rule
• Don’t Block the Event Loop.
14
Thread vertx-eventloop-thread-3 has been blocked for 20458 ms
• Dependencies downstream must be reactive and non-blocking.
• Thread pools used to avoid blocking operations
‒ e.g., I/O, database, file system, calling remote services

15. Programming Paradigms

16. 16
Programming Paradigms
@GET
public Multi<Fruit> get() {
return fruitRepository.streamAll();
}
@GET
public String hello() {
return "hello";
}
Imperative programming
Reactive programming

17. 17

18. Project Loom
• Project Loom will make threads cheaper, which is better for the classic
thread-per-request model.
• It’s focus is in increasing the number of concurrent transactions, instead of
reducing the task switching cost
‒ The context switching cost saved by single event loop thread in reactive programming is seen
by project loom as low impact.
‒ The project loom focus is in increasing throughput, not in reducing latency, and the reactive
model wants to reduce latency.
18

19. Code
19

20. Wrap UP
• Reactive Code is not a Reactive System
• Pay attention to to the On Overflow strategy
• Don’t Block the Event Loop
20

21. Questions?
21
Edgar Domingues

22. 22

23. 23

24. Support Material

25. RESTEasy Reactive
25
• Replace in pom.xml the dependency quarkus-resteasy
‒ With quarkus-resteasy-reactive, to run in the event loop thread using RESTEasy Reactive.
• Don’t forget to annotate your @Blocking methods
‒ Don’t use quarkus-resteasy-mutiny, it runs inside a worker thread using the traditional
RESTEasy.

26. 26
Scores