tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <>
Subject Re: comet end vs. client_disconnect
Date Thu, 12 Feb 2009 02:19:04 GMT
Peter Warren wrote:
> How do I distinguish between a comet END event generated due to a
> client disconnect and an end event generated for some other reason?
> I'm using tomcat 6.0.18 with the nio connector.  On both windows xp
> sp3 and ubuntu 8.10, I'm seeing END events generated when a client
> disconnects and for other situations.  I never receive error events
> with a subtype of CLIENT_DISCONNECT, which is what I was expecting
> when a client disconnects.
> In the aio docs, I read:
> "End will also be called when data is available and the end of file is
> reached on the request input (this usually indicates the client has
> pipelined a request)."
> So END events get generated on a client disconnect but may also get
> generated for pipelined requests.  So how can I tell definitively if a
> client disconnects?
> I also read:
> "note: some of these events require usage of the
> org.apache.catalina.valves.CometConnectionManagerValve"
> so I enabled the CometConnectionManagerValve, but still I don't
> receive error events with a CLIENT_DISCONNECT subtype.
> I've got stack traces for the 2 situations I encounter that generate
> end events.
> This partial stack is from a client disconnect that generates an END event:
> 	Http11NioProcessor.event(SocketStatus) line: 750	
> 	Http11NioProtocol$Http11ConnectionHandler.event(NioChannel,
> SocketStatus) line: 653
> 	NioEndpoint$ line: 2081	
> This partial stack is from something other than a client disconnect
> (maybe a pipelined request?) that generates an END event:
> 	Http11NioProcessor.process(NioChannel) line: 880	
> 	Http11NioProtocol$Http11ConnectionHandler.process(NioChannel) line: 719	
> 	NioEndpoint$ line: 2081
> Note that the traces diverge at NioEndpoint$
> line: 2081 due to the value of NioEndpoint$SocketProcessor.status,
> which is null in the second case.
> Is there a configuration issue that I can remedy to start receiving
> error events with subtype CLIENT_DISCONNECT?  Barring that, is there
> some flag in the CometEvent or some object accessible from the
> CometEvent that I can use to tell if an END event was generated due to
> a client disconnect?

CLIENT_DISCONNECT is only used a subtype of ERROR
and that happens when the socket is closed from the client side

> Thanks,
> Peter
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message