[concurrency-interest] j.u.c.Flow.Subscription.request clarification and javadoc typos

Pavel Rappo pavel.rappo at gmail.com
Sun Sep 13 05:14:22 EDT 2015

Thanks Victor. It indeed makes sense. Also, given the remark [1] ReactiveX gives
on Observable type:

    An Observable is the asynchronous/push “dual” to the
synchronous/pull Iterable

One could immediately see a parallel between 'request(n)' and a number of
calls to 'hasNext'. In this analogy, if 'n' were able to be of any units
other than number of items, it would mean an Iterator could have a

    public boolean hasNext(n);

Which would return 'true' if some number of consecutive 'next' invocations would
deliver 'n' units of something. Which is indeed odd. Instead, iterator is about
a number of iterations, not anything else.


On Fri, Sep 11, 2015 at 6:42 PM, Viktor Klang <viktor.klang at gmail.com> wrote:
> On Fri, Sep 11, 2015 at 4:45 PM, Pavel Rappo <pavel.rappo at gmail.com> wrote:
>> Hi, I have two questions if I may.
>> 1. Given the spec of j.u.c.Flow.Subscription.request method:
>>     /**
>>      * Adds the given number {@code n} of items to the current
>>      * unfulfilled demand for this subscription.  If {@code n} is
>>      * negative, the Subscriber will receive an {@code onError}
>>      * signal with an {@link IllegalArgumentException} argument.
>>      * Otherwise, the Subscriber will receive up to {@code n}
>>      * additional {@code onNext} invocations (or fewer if
>>      * terminated).
>>      *
>>      * @param n the increment of demand; a value of {@code
>>      * Long.MAX_VALUE} may be considered as effectively unbounded
>>      */
>>     public void request(long n);
>> I was wondering how flexible this is. It doesn't seem to allow stating the
>> demand in any other units than items (or number of onNext(T) invocations,
>> which
>> I assume is the same).
>> One of the reviewers of WebSocket API has mentioned that some people
>> "receive a
>> ByteBuffer, but backpressure on the number of bytes consumed" and that the
>> choice of units is actually "an implementation detail" [1]. Is that so?
> The choice of the unit is in number of elements—both the Spec and TCK is
> very clear about that.
>> I can understand the situation when one would have a function f(units)
>> that
>> would map a number of back-pressure units to a number of onNext() calls
>> (or
>> items). So one could always know how many onNext() calls to expect. But
>> what if
>> this is not the case? For example an item is a ByteBuffer of unknown size?
> If the element type is a chunk, then the back-pressure is in number of
> chunks.
> One cannot assume how items will be processed, perhaps the consumer of the
> ByteBuffers is not interested in their contents but is adding more
> information, turning it into a Pair<Foo, ByteBuffer>, who knows?
>> 2. A minor thing. In the javadoc to j.u.c.SubmissionPublisher:
>>     * {@link Flow.Subscriber#onNext onNext}, but exceptions in methods
>>     * {@link Flow.Subscriber#onSubscribe onSubscribe},
>>     * {@link Flow.Subscriber#onError #onError} and
>>     * {@link Flow.Subscriber#onComplete #onComplete} are not recorded or
>> I believe '#' characters are typos at the end of the third and the fourth
>> lines.
>> Thanks.
>> -Pavel
>> -------------------------------------------------------------------------------
>> [1]
>> http://mail.openjdk.java.net/pipermail/net-dev/2015-September/009127.html
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> --
> Cheers,

More information about the Concurrency-interest mailing list