jsr369-experts@servlet-spec.java.net

[jsr369-experts] Re: [servlet-spec users] Re: Re: Re: Re: Clarify onAllDataRead ?

From: Greg Wilkins <gregw_at_intalio.com>
Date: Fri, 6 Feb 2015 09:26:51 +1100

On 5 February 2015 at 19:50, Mark Thomas <markt_at_apache.org> wrote:

> On 05/02/2015 01:41, Greg Wilkins wrote:
> >
> > On 5 February 2015 at 09:35, Greg Wilkins <gregw_at_intalio.com
> > <mailto:gregw_at_intalio.com>> wrote:
> >
> > isFinished() will return false until such time as EOF has been
> > communicated to the application ether by reading -1 or by calling
> > onDataAvailable()
>
> You mean onAllDataRead here don't you?
>

Doh! yes! So much for clarity!

So again, here is the list of behaviours that I would like to javadoc if
there are no objections:

   - onAllDataRead will always be called once and only once when EOF stream
   is reached in the input stream (with the exception for completion - see
   below).
   - The call to onAllDataRead will NOT be concurrent with any other
   callbacks associated with the stream (onDataAvailable, onWritePossible,
   service etc.). onAllDataRead will only be called once the prior callback
   returns.
   - It is possible for -1 to be read from a stream during such a callback
   to onDataAvailable.
   - It is possible for onAllDataRead to be called directly without -1
   being read during a call to onDataAvailable.
   - If isReady() returns false, then a callback to onDataAvailable() will
   be scheduled for when a read can proceed.
   - If the stream is at EOF, then isReady() will return true as -1 can be
   read.
   - isFinished() will return false until such time as EOF has been
   communicated to the application ether by reading -1 or by calling
   onAllDataRead()
   - If the AsyncContext.complete() method is called, or a Servlet.service
   ASYNC dispatch returns without another startAsync, then the
   request/response lifecycle is completed and no further callbacks
   (onDataAvailable, onAllDataRead, onWritePossible, service, filter) will be
   dispatched for that request/response.


Currently our jetty-9.2 release does not act in this way, but our 9.3
snapshot has been made to do so. The result is that it is a bit more
forgiving of user code - ie I think it is harder to write fragile code with
these assumptions. The reason being is that you can choose your EOF
abstraction (onAddDataRead or read -1) you wish to act on and you are
guaranteed of seeing that. Without these assumptions, it is possible for
these EOF signals to be skipped in some circumstances.

cheers




-- 
Greg Wilkins <gregw_at_intalio.com>  @  Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.