On 5 August 2015 at 03:27, Edward Burns <edward.burns_at_oracle.com> wrote:
>
> By "a little traction" Simone is referring to my email last Wednesday as
> well as a couple emails Greg Wilkins and I exchanged. I'll start a
> separate thread about Reacive Streams so we can give this some more
> traction.
>
>
I've had a long thread with the reactive stream guys regarding my concerns
(or my misunderstanding) about error handling in reactive streams:
https://github.com/reactive-streams/reactive-streams-jvm/issues/271
I've used the servlet usage of reactive streams as an example in that
thread (which I recommend you only read if you are really keen).
A result of that thread is that the RS are keen to advise how they think
RSs could be used within the servlet spec, and so another issue has been
opened for that discussion:
https://github.com/reactive-streams/reactive-streams-jvm/issues/288
No idea where it will lead, but good to get the attention of those most
experienced with this style of API to give some advice.
On 5 August 2015 at 18:09, Mark Thomas <markt_at_apache.org> wrote:
>
> Is there a reference available for this that we can read?
>
>
Mark,
Here is Doug Lea's proposal to include Flows (aka Reactive Streams) in
Java-9:
http://cs.oswego.edu/pipermail/concurrency-interest/2015-January/013641.html
I've not seen much discussion on its inclusion or not, so currently I'm
assuming it is going in.
The API is based on that provided by
http://www.reactive-streams.org/ but
it has been wrapped in a single Flow class and the individual interfaces
are scoped by the class (No idea why... I did read the reason somewhere,
but it made no lasting impression... I'm guessing it is fashion :)
Here is the jetty experimentations we've done with the API:
https://github.com/jetty-project/jetty-reactive, which is actually against
the servlet async IO and there is nothing jetty specific in there. But
we are absolute novices with the API and are almost certainly using it
wrong.... so perhaps consider it as an example of everything that you can
do wrong with it :)
However it does establish a Flow that can asynchronous parse form content
as a stream of name value pairs.
cheers
On 6 August 2015 at 01:53, Edward Burns <edward.burns_at_oracle.com> wrote:
> 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
>
--
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com