tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Warren <tomcat.subscript...@gmail.com>
Subject comet end vs. client_disconnect
Date Wed, 11 Feb 2009 20:15:58 GMT
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$SocketProcessor.run() 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$SocketProcessor.run() line: 2081

Note that the traces diverge at NioEndpoint$SocketProcessor.run()
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?

Thanks,
Peter

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


Mime
View raw message