tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: AsyncListener.onError and disconnected client
Date Wed, 24 Apr 2013 18:14:53 GMT
On 24/04/2013 18:38, Rossen Stoyanchev wrote:
> ----- Original Message -----
>> From: "Mark Thomas" <>
>> To: "Tomcat Users List" <>
>> 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
> Thanks for that reference. Is there something in the spec that explicitly makes requires

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.

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

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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message