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

Viktor Klang viktor.klang at gmail.com
Fri Sep 11 13:42:24 EDT 2015

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
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20150911/d4e641f7/attachment.html>

More information about the Concurrency-interest mailing list