[infinispan-dev] Reactive Streams + RxJava

William Burns mudokonman at gmail.com
Mon Jun 19 09:25:01 EDT 2017


On Mon, Jun 19, 2017 at 8:34 AM Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> You’re thinking about a pure implementation play, correct? RxJava or the
> Reactive Stream constructs would not be exposed to the user as API. Am I
> correct?
>

Yes, that is correct. This is only for internal usage. My thought is maybe
when we finally move to Java 9, we may expose the Flow API at some point,
but nothing any time soon.


> Also for posterity, we had backchannel chats about it and you said you
> felt vert.x was not necessarily addressing your needs. Could you elaborate
> a bit here?
>

The main difference is that RxJava [1] has a full suite of utility methods
around reactive streams [2]. Vert.x has some APIs around reactive streams
[3], but it is rather limited.

RxJava is about publishing/consuming your own streams without tying to any
threading model (everything can be done on main thread for example). And it
provides methods of mapping streams to others and even returning blocking
APIs back to the user. Some methods in particular I was looking at were
merge, delay, blockingIterable, rebatch and some others.

Vert.x is really beneficial with reactive programming built upon existing
tools (HTTP, JDBC and others). It also has the event bus and others but
this is built on the vert.x event loop, which we just don't need in
Infinispan. We already have our own threading model and communication over
JGroups.

My usage is to handle multiple streams of data coming from different
locations and merging them together and doing some additional
transformations. I could do this with either of the API, however RxJava
already did a lot of heavy lifting I would have to do otherwise.

Also another side note is that it might be helpful for vert.x to change
over to something more like the upcoming Flow API from Java 9 (maybe [4]
which is pretty much identical currently). RxJava uses this as a base class
for it's Publish/Subscribe.

[1] https://github.com/ReactiveX/RxJava/tree/2.x/src/main/java/io/reactivex
[2]
http://reactivex.io/RxJava/2.x/javadoc/io/reactivex/Flowable.html#blockingIterable()
<https://github.com/ReactiveX/RxJava/blob/2.x/src/main/java/io/reactivex/Flowable.java>
[3]
https://github.com/eclipse/vert.x/tree/master/src/main/java/io/vertx/core/streams
[4]
https://mvnrepository.com/artifact/org.reactivestreams/reactive-streams/1.0.0


>
> Emmanuel
>
> On 15 Jun 2017, at 23:20, William Burns <mudokonman at gmail.com> wrote:
>
> I was thinking more about [1] and I find that I was going to implement
> basically reactive streams. What we have now in github is similar but it
> uses a very crude method of blocking the thread to prevent back pressure.
> This can then cause severe issues as many users have found out when they
> don't close iterator.
>
> Unfortunately reactive streams is just a spec. I am proposing to add
> RxJava [2] as a dependency [2] in the core module to provide access to
> reactive streams and the various conversion methods. This library adds a
> bunch of support for built in back pressure, transformations and much more
> which would reduce the amount of code I would need to write substantially.
>
> In regards to timing, I am thinking this is too close for 9.1, so maybe
> 9.2 or higher.
>
> What do you guys think?
>
> [1] https://issues.jboss.org/browse/ISPN-7865
> [2] https://github.com/ReactiveX/RxJava
> [3] https://mvnrepository.com/artifact/io.reactivex.rxjava2/rxjava/2.1.0
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170619/d38a60f0/attachment-0001.html 


More information about the infinispan-dev mailing list