[concurrency-interest] JDK 9 Flow javadoc example SampleSubscriber requesting

Dávid Karnok akarnokd at gmail.com
Sat Sep 24 10:08:38 EDT 2016


Given a synchronous end-consumer Flow.Subscriber of a Flow.Publisher,
generally there is no reason to request in parts/batches and almost all
should be able to request Long.MAX_VALUE at the beginning. The reason for
it is that such consumers have a natural call-stack blocking and until the
onNext returns, they won't receive another onNext.

One of the few reasons one would use such batching if the onNext
implementation goes async to execute the consumer.accept:

public void onNext(T item) {
  singleThreadedExecutor.execute(() -> {
    if (--count <= 0)
      subscription.request(count = bufferSize - bufferSize / 2);
      consumer.accept(item);
    }
  });
}

Batching has more sense in operators built with the help of Subscribers
(like flatMap and observeOn) but those are too complicated in on themselves
to be shown as examples.

I can understand the example is to show off the features/patterns one can
utilize but it might be worth mentioning the effects of synchronous
consumption with respect to requesting.

Another reason to clarify is that people have consumers implemented as such
in RxJava and wondered why the top source didn't respect their request
amount: it generated 128 elements upfront even though they requested 1 over
a chain of various async stages (and in fact received only one but there
was another 127 ready to be emitted).

RS requesting is a property between two subsequent stages and each stage
can decide - while respecting the spec - how much to prefetch and how to
translate downstream request into an upstream request.




-- 
Best regards,
David Karnok
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20160924/99799861/attachment.html>


More information about the Concurrency-interest mailing list