Entering Reactive Streams Era

Reactor 2.0 development started by the end of 2014, around the same time as Reactive Streams. We were keen on joining the effort and early adopt a backpressure protocol to mitigate our main message-passing limitation: bounded capacity. We delivered in Reactor 2.0 the first attempt to make Reactive Streams implementations of RingBuffer-based schedulers and derived an increasingly popular reactive pattern: Reactive Extensions.

Meanwhile, Reactive Streams started getting traction and an entire ecosystem of libraries discussed this transition. The regular concern ? Implementing Reactive Streams semantics is all but an easy task. We observed an increasing need for a reactive foundation to solve message-passing and implement common streaming operators. We therefore created a dedicated project space for Reactor Core and started a focused effort with Spring Framework team.

Starting from 2.5, Reactor is now organized into multiple projects, maintenance branches such as 2.0.x are left unaltered. This is reflected in release management, for instance Reactor Core 2.5 M1 is the only milestone available and other projects will follow with their exclusive versioning.

To support this new project model, we deployed a new and hopefully more welcoming site on http://projectreactor.io.

A collaborative new take on Reactive Streams

This new organization unlocked a far cheaper ticket price to get involved with the project activities. The project benefits from Spring API design collaboration and direct contributions notably from Sébastien Deleuze and Brian Clozel. Reactor also welcomes the help of new external contributors and reviewers :

• Alex Petrov re-inventing the popular Reactor event routing features.
• Anatoly Kadyshev who works on the amazingly efficient Aeron Reactive Streams bridge for Reactor IO.
• Ben Hale and his team working on the new Reactive Cloud Foundry Client API. More than early adopting Reactor 2.5 Core and Stream, Ben keeps iterating with us on his real-world use cases.
• Damien Vitrac contributing the new project site style and preparing the Reactor Console user experience.
• Dávid Karnok, researcher, main active RxJava committer and author of the excellent Advanced RxJava blog, strongly influenced our internal operational model. Our shared passion for efficiency and reactive patterns led us to create a research space, Reactive Streams Commons.

Dependencies and Collaborations at play with Reactor 2.5

Reactive Streams Commons

The Reactive Streams Commons repository is an open research effort focusing on efficiency with Reactive Extensions and more, for the Reactive Streams specification. It is fully inlined by Reactor Core and Stream which operate as contract gates for the many revolutions the effort focuses on.

"RSC" is therefore a freeform project similar to the JCTools take on concurrent queues. One of its biggest progress is a form of "Fusion" protocol to reduce overhead of most synchronous and some asynchronous stages in a reactive processing chain. Finally, the effort helped fixing more than a hundred of streaming bugs and our testing process now involves RSC unit/integration testing and JMH benchmarks combined with Reactor own integration testing and benchmarks.

Reactor Core 2.5.0.M1

Today's Reactor blog series starts with a joyful event, Reactor Core 2.5.0.M1 release ! Under its new scope and close ties with Reactive Streams Commons, Reactor Core offers just enough Rx coverage to build reactive apps or libraries alike , e.g. Spring Reactive Web support. For the impatient reader, have a look at the already available quickstart on github.

A quick glance at a scatter-gather scenario:

Mono.from(userRequestPublisher)
    .then(userRepository::findUserProfile, 
          userRepository::findUserPaymentMethod)
    .log("user.requests")
    .or(Mono.delay(5)
            .then(n -> Mono.error(new TimeoutException()))
    .mergeWith(userRepository::findSimilarUserDetails)
    .map(userDetailsTuple -> userDetailsTuple.t1.username)
    .publishOn(SchedulerGroup.io())
    .subscribe(responseSubscriber);

In details :

• Flux, a Publisher of 0 to N data signals with a lite Rx scope. Operators include create(), interval(), merge(), zip(), concat(), switchOnError() and switchOnEmpty()

• Mono, a Publisher of 0 or 1 data signal with a lite Rx derived scope adapted to strongly type this specific volume nature. Operators include delay(), then(), any(), and(), or(), otherwise(), otherwiseIfEmpty(), where() and a blocking get().

• New simple scheduling contract based on plain Java interfaces (Runnable, Callable).

-- Featuring SchedulerGroup, TopicProcessor and WorkQueueProcessor. -- Superseed the former Enviroment/Dispatcher couple while answering the same needs and a simple migration path will shortly be documented. No more static state holding references of dispatchers. -- Linked operators : publishOn() and dispatchOn()

• Test support for Publisher sources with TestSubscriber.
• Convert Callable, Runnable, Iterable, Java 8 CompletableFuture, Java 9 Flow.Publisher, RxJava 1 Observable and Single to Reactive Streams ready Flux and Mono, no extra bridge dependency required.
• Fully revamped and integrated Javadoc, including slightly adjusted marble diagrams.
• A micro toolkit of utils and base Subscriber to reuse at will to implement your own Reactive components.

-- A cost-efficient Timer API and implementation (hash-wheel timer). -- New Fusion API to virtually conflate 2 or more stages from a reactive chain -- An adapted QueueSupplier that will provide the right queue for the right capacity

• New Introspection API based on state and flow representations.

-- Publisher Logging with fallback to java.util.logging or SLF4J if available. Can directly be used on Flux and Mono with log() operator. -- Orthogonal to any other contract including Reactive Streams, everything can be Backpressurable , a Completable or be a Receiver producing to a generic Object (possibly a Subscriber), which in return allows us to trace down the full graph of a flow and augment it with state indicators:

What's (on)Next ?

We'd like to collect your very feedback, you can assault the respective issues repository or join our recently created Gitter channel. Stay tuned for the next entry about Reactor Stream 2.5.0.M1, the complete Rx over Reactive Streams implementation.