Greg,
reactive streams are new to me but look interesting. I like your examples
but my point is that we have dumped the complexity of parsing parameters
on applications if they want to receive them as post data using
non-blocking apis. Sure there are neat ways for them to do it but in the
blocking model we provide helper methods for parsing parameters whereas in
the non-blocking model we do not.
Agree Option 2 is memory hungry and not my favorite. Option 1 is preferred
and we have something like your examples in our implementations to handle
the fact that we may need to do several reads before we get a complete
parameter.
Thank you,
Martin Mulholland.
WebSphere Application Server Web Tier Architect
email: mmulholl_at_us.ibm.com
IBM RTP, PO BOX 12195, 503/C227,
3039 Cornwallis Rd, RTP, NC 27709-2195
t/l 444-4319, external (919)-254-4319
From: Greg Wilkins <gregw_at_webtide.com>
To: jsr369-experts_at_servlet-spec.java.net
Date: 12/01/2015 06:49 PM
Subject: [servlet-spec users] [jsr369-experts] Re: Adding support
for obtaining post parameters asynchronously
Martin,
I'm torn between thinking: - "there are many ways to do this, so why
should we pick one? Isn't this a framework's job" vs "We've picked lots
of other 'favourite' solutions in the spec, so we should do this as well".
If we want to support this, then your Option 1 is OK other than its lack
of flow control (see below), but I don't like your Option 2 because of the
size issues (plus Option 2 is easy to implement using Option 1 if somebody
has no size concerns). Note that either solution should deliver
Strings rather than bytes[].
But just to show that there are many ways to skin this cat, here is an
experiment we've done with the reactive streams API that will be in Java
9, that consumes an async stream of ByteBuffer and produces and async
stream of Fields.Field (this is equivalent to your Option 1)
https://github.com/jetty-project/jetty-reactive/blob/master/src/main/java/org/eclipse/jetty/reactive/FormFieldProcessor.java
And here is a similar reactive stream that does your Option 2:
https://github.com/jetty-project/jetty-reactive/blob/master/src/main/java/org/eclipse/jetty/reactive/FormProcessor.java
The good thing about the reactive stream approach over your listener
approach is that it allows back pressure to be applied. Imagine a
client sending a massive form with many many fields. With your option 1,
there is no way for the field consumer to slow the delivery of those
fields, potentially causing either TCP/IP or HTTP2 flow control to slow
the sending of those fields at source.
With reactive streams, the needs for request(int n) signals provides a
back pressure mechanism that can can trigger flow control.
I've still not used reactive streams enough to say I actually like
them.... but they are destined for the JDK... so perhaps they are a good
choice even if we don't luv em?
cheers
On 2 December 2015 at 10:12, Martin Mulholland <mmulholl_at_us.ibm.com>
wrote:
With the introduction of async i/o in Servlet 3.1 it is now possible for
applications to read post data asynchronously. However applications which
process parameters sent as post data can only take advantage of async i/o
if they are willing to parse the parameters themselves without use of the
convenience methods provided by ServletRequest.
I propose this is addressed and we provide a method for applications to
receive parameters as post data using async i/o without having to do their
own parsing. There are many ways to do this. My suggestions are:
Option 1. Add a new parameterListener object with methods
onParameterAvailable, onAllParametersRead, and onError (same equivalent
methods as a readListener). It could be registered with the input stream
just like readListener.
Option 2: Add a new method ServletRequest.addParameters(byte[][]
parameterBytes) This can then be called by the application's readListener
once it has received all of the post data.
Thank you,
Martin Mulholland.
WebSphere Application Server Web Tier Architect
email: mmulholl_at_us.ibm.com
IBM RTP, PO BOX 12195, 503/C227,
3039 Cornwallis Rd, RTP, NC 27709-2195
t/l 444-4319, external (919)-254-4319
--
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com