Bug 46875 - CometConnectionManagerValve: concurrent access on session object when calling HttpSession.invalidate()
CometConnectionManagerValve: concurrent access on session object when calling...
Status: RESOLVED WONTFIX
Product: Tomcat 6
Classification: Unclassified
Component: Catalina
6.0.18
PC All
: P2 major (vote)
: default
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2009-03-19 02:15 UTC by holger.schott
Modified: 2014-02-17 13:48 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description holger.schott 2009-03-19 02:15:04 UTC
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)
Comment 1 Remy Maucherat 2009-03-19 11:23:19 UTC
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).
Comment 2 Mark Thomas 2009-03-25 12:03:04 UTC
I've added try/catch blocks as per Remy's suggestion to trunk and proposed the fix for 6.0.x
Comment 3 Mark Thomas 2009-04-28 03:39:32 UTC
This has been fixed in 6.0.x and will be included in 6.0.20 onwards.
Comment 4 holger.schott 2009-05-29 14:12:48 UTC
What about reliability? I can not rely on a CometEvent with EventSubType.SESSION_END. That's really bad.
Comment 5 Mark Thomas 2009-07-16 13:45:42 UTC
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.