VMware offers training and certification to turbo-charge your progress.Learn more
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.
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 :
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.
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 :
where()and a blocking
-- Featuring SchedulerGroup, TopicProcessor and WorkQueueProcessor.
-- Superseed the former
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 :
Publishersources with TestSubscriber.
Iterable, Java 8
CompletableFuture, Java 9
Flow.Publisher, RxJava 1
Singleto Reactive Streams ready
Mono, no extra bridge dependency required.
-- 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
Publisher Logging with fallback to
java.util.logging or SLF4J if available. Can directly be used on
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:
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.