tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rossen Stoyanchev <rstoyanc...@vmware.com>
Subject Re: AsyncListener.onError and disconnected client
Date Thu, 25 Apr 2013 12:20:47 GMT

----- Original Message -----
> From: "Mark Thomas" <markt@apache.org>
> To: "Tomcat Users List" <users@tomcat.apache.org>
> Sent: Wednesday, April 24, 2013 2:14:53 PM
> Subject: Re: AsyncListener.onError and disconnected client
> 
> On 24/04/2013 18:38, Rossen Stoyanchev wrote:
> >
> > ----- Original Message -----
> >> From: "Mark Thomas" <markt@apache.org>
> >> To: "Tomcat Users List" <users@tomcat.apache.org>
> >> Sent: Wednesday, April 24, 2013 12:47:54 PM
> >> Subject: Re: AsyncListener.onError and disconnected client
> >>
> >> On 24/04/2013 16:33, Rossen Stoyanchev wrote:
> >>> Hi,
> >>>
> >>> I've seen various discussions here and on the web but I haven't
> >>> found
> >>> a conclusive answer. Why does an AsyncListener not receive
> >>> onError
> >>> notifications when a client disconnects?
> >>
> >> Because the Servlet EG says that is the required behaviour. The EG
> >> is
> >> currently revisiting that decision. See
> >> https://java.net/jira/browse/SERVLET_SPEC-44
> >
> > Thanks for that reference. Is there something in the spec that
> > explicitly makes requires this?
> 
> Not that I am aware of which why I said "EG" rather than
> "specification".
> 
> > The JIRA ticket is about adding a "disconnect" callback but I can
> > imagine in the very least, onComplete can be called. After the
> > connection is over.
> 
> onComplete should be called once the connection times out.

My understanding is that onComplete is always called regardless of how the async request completed,
i.e. following onTimeout, or onError. I would expect it to be called after a client disconnect
as well for consistency. Also I wonder if a disconnect method is even needed? The onError
method could be called indicating that the "asynchronous operation has failed to complete"
(from the Javadoc). That's actually what I expected when I first tried.

> >>> To my knowledge there is nothing inherent in NIO and TCP that
> >>> prevents the server from detecting that the client has
> >>> disconnected.
> >>> The WebSocket implementation detects disconnected clients
> >>> immediately
> >>> and other HTTP servers (e.g. node) seem to be able to do this.
> >>> What
> >>> is it about the Servlet async support that prevents it from
> >>> knowing
> >>> when a client has disconnected?
> >>
> >> It would mean having to ditch the BIO connector / or not being
> >> able
> >> to pass the TCK (assuming the TCK tested this) when using the BIO
> >> connector.
> >
> > I guess this goes back to the previous question about whether there
> > is an explicit requirement and therefore test. Why would a TCK
> > test explicitly check that disconnects are not communicated to
> > AsyncListeners? Or is it a more indirect consequence of some other
> > requirement?
> 
> My point was that if a disconnect event was added to the spec then
> the BIO connector could never be spec compliant.

If I understand correctly, you're saying the BIO connector can not detect a client disconnect.

> On reflection, it might not be that bad. The event could be fired
> just not when the client disconnects. It would have to wait until an
> attempt was made to read from / write to the socket.

That's actually not very different from the current situation where I catch any exceptions
while trying to write to the response and then call asyncContext.complete(). I suppose it
would make it more clear that a client has disconnected (as opposed to some other error),
but once writing to the response has raised an error, it doesn't make a big difference what
the error is.


Rossen

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message