Reactive Programming in Java: How, Why, and Is It Worth Doing? Reactive Streams spec
Reactive Programming in Java: How, Why, and Is It Worth Doing? Reactive Streams spec
Time for another article in our series on reactive programming in Java. This time we’re tackling reactive streams spec.
13 вер 2021
2177
Інші статті
How to debug and solve the issue of Datanodes which were reported as Bad nodes?
How to incrementally migrate the data from RDBMS to Hadoop using Sqoop Incremental Last Modified technique?
How to implement Slowly Changing Dimensions(SCD) Type 2 in Spark?
How to incrementally migrate the data from RDBMS to Hadoop using Sqoop Incremental Append technique?
Why MongoDB don't fetch all the matching documents for the query fired
How to solve the issue of full disk utilization in HDFS Namenode
Can We Use HDFS as Back-up Storage?
How to do Indexing in MongoDB with Elastic Search? Part 1
How to do Indexing in MongoDB with Elastic Search? Part 2
How to store data on browser using NoSQL IndexedDB?
Reactive Streams spec
Reactive streams were included in Java 9 as a specification.
While previous technologies (Completable Future, Fork/Join framework) were implemented in the JDK, reactive streams have no implementation. There is only a very brief specification. There are only 4 interfaces:
If we look at our example from the Twitter picture, we can say that:
Publisher is the girl who tweets;
Subscriber is a subscriber. The Subscriber determines what to do if:
- We started listening to the stream (onSubscribe). Once we subscribed successfully, this function will be called
- Another value appeared in the stream (onNext)
- An error occurred (onError)
- The stream is completed (onComplete)
Subscription — we have a subscription which we can cancel (cancel) or request a certain number of values (request(long n)). We can define behavior for each next value or can take values manually.
Processor is both Subscriber and Publisher. It receives some values and puts them somewhere.
If you want to subscribe to something, call Subscribe and then receive updates every time. You can request them manually by using request. Or you can define behavior when a new message arrives (onNext): what to do if a new message appeared, what to do if an error occurred, and what to do if the Publisher completed the stream. We can define these callbacks or cancel.
PUSH / PULL Models
There are two stream models:
Push model — when there is “pushing” of values.
For example, you are subscribed to someone on Telegram or Instagram and receive notifications (called “push notifications”, you don’t request them, they come automatically). These could be, for example, pop-up messages. You can define how to react to each new message.
Pull model — when you make a request by yourself.
For instance, you don't want to subscribe, as there is too much information, but you want to visit the site and read the news.
For the Push model, we define callbacks, i.e., functions that will be called when the following message arrives, and for the Pull model, we can use the request method when we want to learn something new.
The Pull model is essential for Backpressure. What’s that?
You could be spammed by your subscriptions. In that case, you are unable to read them all, and there's a chance that you may lose critical data — they would just get lost in that message flow. When, due to a considerable information flow, the Subscriber cannot handle everything published by the Publisher, we have Backpressure.
In that case, you can use the Pull model and make a request for one message, firstly from data streams that are most important for you.