Reactive Streams Specification for the JVM
Reactive Streams Specification for the JVM
The purpose of Reactive Streams is to provide a standard for asynchronous stream processing with non-blocking backpressure.
The latest release is available on Maven Central as
<dependency>
<groupId>org.reactivestreams</groupId>
<artifactId>reactive-streams</artifactId>
<version>1.0.4</version>
</dependency>
<dependency>
<groupId>org.reactivestreams</groupId>
<artifactId>reactive-streams-tck</artifactId>
<version>1.0.4</version>
<scope>test</scope>
</dependency>
Handling streams of data—especially “live” data whose volume is not predetermined—requires special care in an asynchronous system. The most prominent issue is that resource consumption needs to be carefully controlled such that a fast data source does not overwhelm the stream destination. Asynchrony is needed in order to enable the parallel use of computing resources, on collaborating network hosts or multiple CPU cores within a single machine.
The main goal of Reactive Streams is to govern the exchange of stream data across an asynchronous boundary – think passing elements on to another thread or thread-pool — while ensuring that the receiving side is not forced to buffer arbitrary amounts of data. In other words, backpressure is an integral part of this model in order to allow the queues which mediate between threads to be bounded. The benefits of asynchronous processing would be negated if the backpressure signals were synchronous (see also the Reactive Manifesto), therefore care has been taken to mandate fully non-blocking and asynchronous behavior of all aspects of a Reactive Streams implementation.
It is the intention of this specification to allow the creation of many conforming implementations, which by virtue of abiding by the rules will be able to interoperate smoothly, preserving the aforementioned benefits and characteristics across the whole processing graph of a stream application.
It should be noted that the precise nature of stream manipulations (transformation, splitting, merging, etc.) is not covered by this specification. Reactive Streams are only concerned with mediating the stream of data between different API Components. In their development care has been taken to ensure that all basic ways of combining streams can be expressed.
In summary, Reactive Streams is a standard and specification for Stream-oriented libraries for the JVM that
The Reactive Streams specification consists of the following parts:
The API specifies the types to implement Reactive Streams and achieve interoperability between different implementations.
The Technology Compatibility Kit (TCK) is a standard test suite for conformance testing of implementations.
Implementations are free to implement additional features not covered by the specification as long as they conform to the API requirements and pass the tests in the TCK.
The API consists of the following components that are required to be provided by Reactive Stream implementations:
A Publisher is a provider of a potentially unbounded number of sequenced elements, publishing them according to the demand received from its Subscriber(s).
In response to a call to Publisher.subscribe(Subscriber) the possible invocation sequences for methods on the Subscriber are given by the following protocol:
onSubscribe onNext* (onError | onComplete)?
This means that onSubscribe is always signalled,
followed by a possibly unbounded number of onNext signals (as requested by Subscriber) followed by an onError signal if there is a failure, or an onComplete signal when no more elements are available—all as long as the Subscription is not cancelled.
| Term | Definition |
|---|---|
| Signal | As a noun: one of the onSubscribe, onNext, onComplete, onError, request(n) or cancel methods. As a verb: calling/invoking a signal. |
| Demand | As a noun, the aggregated number of elements requested by a Subscriber which is yet to be delivered (fulfilled) by the Publisher. As a verb, the act of request-ing more elements. |
| Synchronous(ly) | Executes on the calling Thread. |
| Return normally | Only ever returns a value of the declared type to the caller. The only legal way to signal failure to a Subscriber is via the onError method. |
| Responsivity | Readiness/ability to respond. In this document used to indicate that the different components should not impair each others ability to respond. |
| Non-obstructing | Quality describing a method which is as quick to execute as possible—on the calling thread. This means, for example, avoids heavy computations and other things that would stall the caller´s thread of execution. |
| Terminal state | For a Publisher: When onComplete or onError has been signalled. For a Subscriber: When an onComplete or onError has been received. |
| NOP | Execution that has no detectable effect to the calling thread, and can as such safely be called any number of times. |
| Serial(ly) | In the context of a Signal, non-overlapping. In the context of the JVM, calls to methods on an object are serial if and only if there is a happens-before relationship between those calls (implying also that the calls do not overlap). When the calls are performed asynchronously, coordination to establish the happens-before relationship is to be implemented using techniques such as, but not limited to, atomics, monitors, or locks. |
| Thread-safe | Can be safely invoked synchronously, or asychronously, without requiring external synchronization to ensure program correctness. |
public interface Publisher<T> {
public void subscribe(Subscriber<? super T> s);
}
| ID | Rule |
|---|---|
| 1 | The total number of onNext´s signalled by a Publisher to a Subscriber MUST be less than or equal to the total number of elements requested by that Subscriber´s Subscription at all times. |
| :bulb: | The intent of this rule is to make it clear that Publishers cannot signal more elements than Subscribers have requested. There’s an implicit, but important, consequence to this rule: Since demand can only be fulfilled after it has been received, there’s a happens-before relationship between requesting elements and receiving elements. |
| 2 | A Publisher MAY signal fewer onNext than requested and terminate the Subscription by calling onComplete or onError. |
| :bulb: | The intent of this rule is to make it clear that a Publisher cannot guarantee that it will be able to produce the number of elements requested; it simply might not be able to produce them all; it may be in a failed state; it may be empty or otherwise already completed. |
| 3 | onSubscribe, onNext, onError and onComplete signaled to a Subscriber MUST be signaled serially. |
| :bulb: | The intent of this rule is to permit the signalling of signals (including from multiple threads) if and only if a happens-before relation between each of the signals is established. |
| 4 | If a Publisher fails it MUST signal an onError. |
| :bulb: | The intent of this rule is to make it clear that a Publisher is responsible for notifying its Subscribers if it detects that it cannot proceed—Subscribers must be given a chance to clean up resources or otherwise deal with the Publisher´s failures. |
| 5 | If a Publisher terminates successfully (finite stream) it MUST signal an onComplete. |
| :bulb: | The intent of this rule is to make it clear that a Publisher is responsible for notifying its Subscribers that it has reached a terminal state—Subscribers can then act on this information; clean up resources, etc. |
| 6 | If a Publisher signals either onError or onComplete on a Subscriber, that Subscriber’s Subscription MUST be considered cancelled. |
| :bulb: | The intent of this rule is to make sure that a Subscription is treated the same no matter if it was cancelled, the Publisher signalled onError or onComplete. |
| 7 | Once a terminal state has been signaled (onError, onComplete) it is REQUIRED that no further signals occur. |
| :bulb: | The intent of this rule is to make sure that onError and onComplete are the final states of an interaction between a Publisher and Subscriber pair. |
| 8 | If a Subscription is cancelled its Subscriber MUST eventually stop being signaled. |
| :bulb: | The intent of this rule is to make sure that Publishers respect a Subscriber’s request to cancel a Subscription when Subscription.cancel() has been called. The reason for eventually is because signals can have propagation delay due to being asynchronous. |
| 9 | Publisher.subscribe MUST call onSubscribe on the provided Subscriber prior to any other signals to that Subscriber and MUST return normally, except when the provided Subscriber is null in which case it MUST throw a java.lang.NullPointerException to the caller, for all other situations the only legal way to signal failure (or reject the Subscriber) is by calling onError (after calling onSubscribe). |
| :bulb: | The intent of this rule is to make sure that onSubscribe is always signalled before any of the other signals, so that initialization logic can be executed by the Subscriber when the signal is received. Also onSubscribe MUST only be called at most once, [see 2.12]. If the supplied Subscriber is null, there is nowhere else to signal this but to the caller, which means a java.lang.NullPointerException must be thrown. Examples of possible situations: A stateful Publisher can be overwhelmed, bounded by a finite number of underlying resources, exhausted, or in a terminal state. |
| 10 | Publisher.subscribe MAY be called as many times as wanted but MUST be with a different Subscriber each time [see 2.12]. |
| :bulb: | *The intent of this rule is to have callers of subscribe be aware that a generic Publisher and a generic Subscriber cannot be assumed to support being attached m |
No open issues yet, or sync has not completed.