On 04/08/2015 18:44, Edward Burns wrote:
EB> For the upcoming JavaOne EDR, I would like to at least know whether or
EB> not we should address the Reactive Streams initative sponsored by
EB> TypeSafe in Servlet 4.
>>>>> On Wed, 05 Aug 2015 09:09:29 +0100, Mark Thomas <markt_at_apache.org> said:
MT> I think it is something we should consider. I don't have a view on
MT> whether we should or not at this point. I don't feel I know enough to
MT> make a sensible decision.
EB> I am aware that Greg Wilkins has done some exploratory work in this
EB> area,
MT> Is there a reference available for this that we can read?
Greg Cc'd the list with the following from his webtide address, but I
don't think it made it through since he is subscribed with his intalio
address. Greg, please follow up using your intalio address or subscribe
with your webtide address and then follow up.
>>>>> On Wed, 5 Aug 2015 08:55:03 +1000, Greg Wilkins said:
GW> I've had a long thread with the reactive stream guys regarding my concerns
GW> (or my misunderstanding) about error handling in reactive streams:
GW>
https://github.com/reactive-streams/reactive-streams-jvm/issues/271
GW> I've used the servlet usage of reactive streams as an example in that
GW> thread (which I recommend you only read if you are really keen).
GW> A result of that thread is that the RS are keen to advise how they think
GW> RSs could be used within the servlet spec, and so another issue has been
GW> opened for that discussion:
GW>
https://github.com/reactive-streams/reactive-streams-jvm/issues/288
GW> No idea where it will lead, but good to get the attention of those most
GW> experienced with this style of API to give some advice.
EB> and I am intrigued with his idea of being able to leverage the
EB> flow-control facility of HTTP/2 to convey "backpressure".
MT> They look to be a very good match since in both cases it is the receiver
MT> that controls how much data the sender can send.
Yes, I look forward to hearing Greg's expertise here.
EB> (As an aside, I would love it if someone would explain how backpressure
EB> differs from congestion control a la RFC 5681.)
MT> Based on my limited understanding, congestion control involves the
MT> sender sending more and more data until it detects that the recipient is
MT> overwhelmed and can't cope. Back pressure (as used in reactive streams)
MT> involves the recipient telling the sender how much data it may send.
Another difference occurred to me while listening to last week's
Reactive Explained webinar [1]. 47:57 The case of synchronous method
invocation can be thought of as getting back-pressure for free, but in
the least optimal way, from time-performance perspective: you know that you
can't send more because you can only send more when the method returns.
Though the webinar presenter, Konrad Malawski, didn't say it explicitly,
I think the idea with back-pressure is to convey that knowledge of "when
you can send more" by a means other than blocking. I think the
challenge for us here in Servlet is to keep it simple. While blocking
may be sub-optimal from a time-performance perspective, it is supremely
optimal from a reasoning and developer-performance perspective.
Ed
[1]
http://www.typesafe.com/resources/video/reactive-revealed-13-async-nio-back-pressure-and-message-driven-vs-event-driven?mkt_tok=3RkMMJWWfF9wsRokuK7OZKXonjHpfsX67eUuUaG%2FlMI%2F0ER3fOvrPUfGjI4DT8dgI%2BSLDwEYGJlv6SgFT7XNMa5jwrgKWxM%3D
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 64 Business days til JavaOne 2015
| 79 Business days til DOAG 2015