Flow programming: subscriber and publisher to keep track of count?

GhostCat salutes Monica C. :

I came over an article regarding the new Flow related interfaces in Java9. Example code from there:

public class MySubscriber<T> implements Subscriber<T> {  
  private Subscription subscription;    
  @Override  
  public void onSubscribe(Subscription subscription) {  
    this.subscription = subscription;  
    subscription.request(1); //a value of  Long.MAX_VALUE may be considered as effectively unbounded  
  }        
  @Override  
  public void onNext(T item) {  
    System.out.println("Got : " + item);  
    subscription.request(1); //a value of  Long.MAX_VALUE may be considered as effectively unbounded  
   }

As you can see, onNext() requests one new item to be pushed.

Now I am wondering:

if onSubscribe() requested, say 5 items
and after the first item gets delivered, request(1) is called like above

Is the server now expected to send

five items ( 5 requested. -1 sent. +1 requested)
or one item (because the previous request gets "discarded" by that new request)

In other words: when request() is called several times, do those numbers add up; or are previous requests "discarded"?

Leading to the question title - whether the subscriber needs to keep track about received items, in order to avoid requesting "too many" items at some point.

Nicolai :

As Sotirios points out, the request method's Javadoc states (emphasis mine):

Adds the given number n of items to the current unfulfilled demand for this subscription. If n is less than or equal to zero, the Subscriber will receive an onError signal with an IllegalArgumentException argument. Otherwise, the Subscriber will receive up to n additional onNext invocations (or fewer if terminated).

So the answer is clearly yes, the subscriber needs to keep track of items. In fact, that's the whole point of the mechanism. Some background: The request method is meant to allow the subscriber to apply backpressure, informing upstream components that it is overloaded and "needs a break". It is hence the subscriber's (and only its) task to carefully vet when and how many new items to request. In that line it can not "reconsider" and lower the number of items to receive.

Lowering the number would also make the communication between publisher and subscriber "non-monotonic" in the sense that the number of totally requested items could suddenly lower (as it stands it can only increase). This is not only annoying in an abstract sense, it poses concrete consistency problems: The publisher could be in the process of delivering a few items when the subscriber suddenly drops the number of requested items to 1 - what now?

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=438318&siteId=1