jsr369-experts@servlet-spec.java.net

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

From: Greg Wilkins <gregw_at_intalio.com>
Date: Wed, 4 Feb 2015 18:42:36 +1100

All,

Another related concern is what should happen with async IO callbacks if
AsyncContext.complete() has been called?


Let's say that both input.isReady() and out.isReady() have returned false,
so that we have a pending callback to both onDataAvailable() and
onWritePossible().

If during the first of these callbacks (say onDataAvailable()), the
AsyncContext.complete() method is called, then should the application
expect onWritePossible() to be called afterwards?

Ie can we keep calling IO callbacks after the lifecycle of the
request/response is complete?

cheers







On 12 January 2015 at 20:57, Mark Thomas <markt_at_apache.org> wrote:

> On 04/01/2015 22:27, Stuart Douglas wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Greg Wilkins" <gregw_at_intalio.com>
> >> To: jsr369-experts_at_servlet-spec.java.net
> >> Sent: Saturday, 3 January, 2015 4:39:21 AM
> >> Subject: [jsr369-experts] Clarify onAllDataRead ?
> >>
> >> I think we need to clarify when onAllDataRead should be called.
> >>
> >> My understanding is that once isReady() has returned false, a callback
> is
> >> scheduled:
> >>
> >> - If the IO that arrives is data, then onDataAvailable() is called.
> >> - If the IO that arrives is EOF, then onAllDataRead() is called.
> >>
> >> But it is possible for the code within onDataAvailable to read, call
> >> isReady() and get a true result and then read -1 for the EOF. In that
> >> case, should onAllDataRead() be called? If so should it wait until the
> >> call to onDataAvailable() has returned?
> >>
> >> I can see it two ways:
> >>
> >> Either we have a callback paradigm that is triggered by isReady()==false
> >> and that once that occurs there should be one and only one callback to
> >> either onDataAvailable or to onAllDataRead()
> >>
> >> OR
> >>
> >> onAllDataRead() is a separate callback paradigm to the onDataAvailable
> and
> >> will be called regardless once EOF is received.
> >>
> >> I think the former is simpler to implement, but might cause surprises
> for
> >> application developers who expect it always to be called.
> >>
> >> The problem with the later is that it means that an onAllDataRead()
> >> callback can come even if isReady()!=false. This breaks the fundamental
> >> callback paradigm that a callback will only occur if isReady() has
> called
> >> false.
> >>
> >> thoughts?
> >>
> >
> > My gut feeling is that onAllDataRead should always be called, regardless
> of if a -1 was returned from onDataAvailable.
>
> Agreed.
>
> > In this case I think the obvious thing to do is to immediately call
> onAllDataRead after onDataAvailable has finished, regardless of if the user
> has called isReady(). I know this is a slightly different callback
> semantic, but I don't think it really matters.
>
> Also agreed.
>
> > If you don't call onAllDataRead in all cases then you have a situation
> where a user has to handle EOF in two different places (I know they can
> just delegate to the onAllDataRead method, but it still seems a bit odd).
> >
> >> As a secondary question, if EOF has arrived, but neither -1 has been
> read
> >> or onAllDataRead() called, should isFinished() return true?
> >
> > I don't think it should return true until this notification has been
> delivered to the user. Otherwise some layer of code could check this flag
> and take some action based on the isFinished flag, however the read
> listener may not have been notified yet. It also seems counter intuitive
> that callbacks could still be pending when isFinished() returns true.
>
> Tomcat doesn't do this currently. We actually use the return value of
> isFinished() to check if onAllDataRead() should be called. However, I've
> no objection to clarifying the behaviour of isFinished() so it returns
> false until onAllDataRead() has completed.
>
> Mark
>
>


-- 
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.