A Second Generation Reactive Foundation for the JVM

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 kadsyshev  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 the overhead of most synchronous and some asynchronous stages in a reactive processing chain.
finally, the effort helped to fix 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 quick start 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  .
  – superseded 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.
  – the monitoring console uses this very same api to introspect reactive streams and more
  – 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.