|Summary:||HttpSessionListener.sessionCreated() is called a second time when user is authenticated with no matching sessionDestroyed() call.|
|Product:||Tomcat 5||Reporter:||Joachim Sauer <jsa>|
|Component:||Catalina||Assignee:||Tomcat Developers Mailing List <dev>|
Description Joachim Sauer 2011-04-08 05:54:06 UTC
When my web application has a HttpSessionListener configured in its web.xml, then that classes sessionCreated() is called when a user is assigned a new session. However, that method is *also* called when that user authenticates itself and the session is assigned a new ID (whether or not this is actually a "new session" can be disputed, but that's not the point of this bug). When the session is removed (due to a timeout, for example), then a single sessionDestroyed() call is executed. When the HttpSessionListener manages some kind of external resource, this behaviour leads to a resource leak, because sessionCreated() is called twice, while sessionRemoved() is only called once! I'm aware of the reason for changing the session ID and (somehow) understand why sessionCreated() is called again (after all there's a new session ID), but there must be *some* way for the SessionListener to be notified that the "old session" no longer exists. The same behaviour is seen in Tomcat 6.0 (and probably 5.5 as well, but I didn't test that).
Comment 1 Joachim Sauer 2011-04-08 05:56:27 UTC
By the way, the change that introduced this issue was the fix for bug #47774.
Comment 2 Joachim Sauer 2011-04-08 05:57:14 UTC
(In reply to comment #1) > By the way, the change that introduced this issue was the fix for bug #47774. Oops, wrong bug number: #45255 is the correct one!
Comment 3 Mark Thomas 2011-04-16 18:36:08 UTC
Fixed in 7.0.x for 7.0.13. Proposed for 6.0.x and 5.5.x
Comment 4 Mark Thomas 2011-06-14 11:41:58 UTC
Fixed in 6.0.x and will be included in 6.0.33 onwards.
Comment 5 Konstantin Kolinko 2011-08-22 12:10:26 UTC
Fixed in 5.5.x and will be in 5.5.34.