[jsr369-experts] Re: [servlet-spec users] Re: Reactive Streams and Servlet 4: synergy or no?

From: Wenbo Zhu <wenboz_at_google.com>
Date: Thu, 27 Aug 2015 15:57:54 -0700

On Fri, Aug 7, 2015 at 5:07 AM, Edward Burns <edward.burns_at_oracle.com>

> >>>>> On Fri, 7 Aug 2015 08:41:36 +1000, Greg Wilkins <gregw_at_webtide.com>
> said:
> GW> Mark,
> GW> Here is Doug Lea's proposal to include Flows (aka Reactive Streams) in
> GW> Java-9:
> GW>
> http://cs.oswego.edu/pipermail/concurrency-interest/2015-January/013641.html
> GW> I've not seen much discussion on its inclusion or not, so currently I'm
> GW> assuming it is going in.
> At this point all we can say is that the idea has not yet been rejected
> out of hand. Also, we have to remember that the idea's inclusion or
> absence in JDK 9 only impacts our design regarding how we resolve our
> design with it when we get to Java EE 9 running on Java SE 9. In other
> words, we can't use this work directly, but we darn well better play
> nice and consistent with it when we get to EE/SE 9.


Also on a) congestion control v.s. b) back-pressures ... IMO

a) protects the network too, and it's almost always hop-by-hop, to avoid
pushing too much data into the "network"
b) back-pressure, which I often refer to as (end-to-end) flow control is to
allow the receiver to notify the send to slow down or stop

HTTP relies on a) to propagate back-pressures b) as a result of "transport
coupling" ... but this would be another topic, and we are only concerned by
the API surface of enabling b).


The time-performance aspect of blocking APIs (for enabling back-pressures)
is interesting, but I am not entirely sure how an async API may help,
without exposing transport-level detail, e.g. .. or is this the idea on
leveraging HTTP/2 specific facilities?

> Thanks,
> Ed
> --
> | edward.burns_at_oracle.com | office: +1 407 458 0017
> | 62 Business days til JavaOne 2015
> | 77 Business days til DOAG 2015