ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lalit Kumar Jha <lalitj....@gmail.com>
Subject Re: Brainstorming about Reactive Streams
Date Wed, 23 Sep 2015 14:45:21 GMT
Summarizing this:

*Goal*: All data flow/stream in system adhere to “Reactive Streams” API,
includes data ingestion, async computation,  compute result/stream
aggregation.

*Benefits*:


   - Common interface for all data transfer/exchange/processing.
   - Streaming data ingestion can compose complex stream processing in a
   standard (interoperable dropin implementation replacement) fashion, like
   filter or aggregate streaming data, merge multiple stream etc.


   - Compose multiple async compute jobs results as streams.


*Design*: To overcome “Cons of Exposing Reactive Stream APIs instead of
RxJava (or other implementation)” mentioned at
https://github.com/ReactiveX/RxJava/wiki/Reactive-Streams

#1. Follow recommended approach there.


#2. Rather than having streaming (data transfer) stream processing logic
(filter, merge, flatMap) in Consumer, treat them as a separate concern, and
wrap Publisher/Consumer in concrete classes.

This is discouraged by RxJava, but will keep standard and non standard
implementation separate and will allow using multiple libraries for
different use-cases. Rather than having this behaviour tightly coupled in
Consumer.



On Wed, Sep 23, 2015 at 6:29 PM, Raul Kripalani <raulk@apache.org> wrote:

> Yeah, in my original post I already pointed out that Reactive Streams is a
> proposed standard but not an implementation.
>
> My proposal was to go with RxJava 1.0 + the Reactive Streams adapter (
> https://github.com/ReactiveX/RxJavaReactiveStreams) for now, as that would
> allow users to benefit from things like Hystrix whose base is RxJava 1.0,
> while keeping their code future-proof for when RxJava 2.0 is released with
> a native RS interface.
>
> Thanks for chiming in.
>
> Raúl.
>
> On Wed, Sep 23, 2015 at 1:35 PM, akarnokd <akarnokd@gmail.com> wrote:
>
> > I'd definitely go on a Reactive-Streams path (although I don't know what
> > Apache Ignite does), however, there seems to be a small confusion around
> > RS.
> > RS is a set of 4 interfaces and practically unusable on its own. One
> needs
> > a
> > library built around it such as Project Reactor, Akka Streams and RxJava
> > 2.0. Such library, likely, will also slip into the API itself due to its
> > usefulness.
> >
> > For example, the following API is inconvenient to use but is definitely
> > cutting-edge:
> >
> > Publisher<Data> getData();
> >
> > but you can only subscribe to it in its plain form or wrap it with one of
> > the libraries:
> >
> > Observable.fromPublisher(getData()).map().filter().group()...
> >
> > I'm not sure about the others, but RxJava 2.0 Observable (which later may
> > be
> > renamed to Flowable) implement Publisher directly, therefore, the
> following
> > getData() may return an RxJava Observable and still be consumable via
> > Reactor or Akka (after wrapping/fluent-conversion, of course):
> >
> > getData().to(Streams::from).dispatchOn(...)
> >
> > Although I'm pretty confident that RxJava 2.0 works right now, it is
> still
> > considered alpha and based on past experience with its gatekeepers, it
> may
> > take 6-12 months until an official release comes out.
> >
> >
> >
> > --
> > View this message in context:
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Brainstorming-about-Reactive-Streams-tp3346p3422.html
> > Sent from the Apache Ignite Developers mailing list archive at
> Nabble.com.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message