When calling invalidate() on an valid HttpSession object CometConnectionManagerValve methods sessionDestroy(HttpSessionEvent se) and event(Request request, Response response, CometEvent event) are called concurrently. So either a CometEvent with EventType.END and EventSubType.SESSION_END is never signaled via sessionDestroyed(...) or the HttpSession object has become invalid and the attribute holding comet requests can not be set or removed via event(...). I have configured CometConnectionManagerValve as a Valve element in context.xml and also as a Listener element in my applications web.xml. see this stacktrace 'sessionDestroy() was a bit faster': An exception or error occurred in the container during the request processing java.lang.IllegalStateException: removeAttribute: Session already invalidated at org.apache.catalina.session.StandardSession.removeAttribute(StandardSession.java:1206) at org.apache.catalina.session.StandardSession.removeAttribute(StandardSession.java:1181) at org.apache.catalina.session.StandardSessionFacade.removeAttribute(StandardSessionFacade.java:140) at org.apache.catalina.valves.CometConnectionManagerValve.event(CometConnectionManagerValve.java:335) at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:179) at org.apache.catalina.valves.ValveBase.event(ValveBase.java:200) at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:128) at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:198) at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:750) at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:653) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:2081) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:637)
I think you have a fair point, but not much can be done about it. These events are asynchronous, so the most likely is that it will be processed after the session is gone, and not much can be done about that. I think the calls to the session should be safer (wrapped with a try/catch).
I've added try/catch blocks as per Remy's suggestion to trunk and proposed the fix for 6.0.x
This has been fixed in 6.0.x and will be included in 6.0.20 onwards.
What about reliability? I can not rely on a CometEvent with EventSubType.SESSION_END. That's really bad.
As Remy said, there isn't much that can be done due to the async nature of these events. If you can see a potential approach, then patches are always welcome.