Reactive Streams defines interfaces and signaling rules for nonblocking asynchronous stream processing with integrated backpressure. It lets consumers control how quickly producers emit data, supporting responsive reactive applications. section 8.2.1 section 7.7
The specification organizes communication around four interfaces:
- Publisher produces items. section 8.2.1
- Subscriber consumes items and receives lifecycle callbacks. section 8.2.1
- Subscription links exactly one Publisher with exactly one Subscriber and carries demand through request(n). section 8.2.1
- Processor acts as both a Publisher and a Subscriber. section 8.2.1
Processing starts when a Subscriber subscribes to a Publisher. The Publisher supplies a Subscription, the Subscriber requests a number of items, and the Publisher emits them through onNext. Processing ends with onComplete or onError. Reducing requested demand applies backpressure when consumption cannot keep up. section 8.2.1
Nonblocking database persistence
A Quarkus Reservation service can return a Mutiny Uni from a persistence operation. The database insert proceeds without blocking the I/O thread; downstream callbacks run after completion, and the JAX-RS request resumes when the result is available. section 8.4.1
Figure 8.4 The example interaction between Reactive Streams Publisher and Subscriber
Follow the Publisher–Subscriber interaction to see subscription, demand, item delivery, completion, and error signaling as one sequence. section 8.2.1
Although the interfaces appear simple, implementing them directly is discouraged because the specification and its Technology Compatibility Kit are complex. Mutiny provides compatible types, including Uni and Multi, so applications can use the model without implementing the protocol themselves. section 8.2.1 section 7.7
