tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 51042] New: HttpSessionListener.sessionCreated() is called a second time when user is authenticated with no matching sessionDestroyed() call.
Date Fri, 08 Apr 2011 09:54:09 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=51042

           Summary: HttpSessionListener.sessionCreated() is called a
                    second time when user is authenticated with no
                    matching sessionDestroyed() call.
           Product: Tomcat 7
           Version: 7.0.11
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Catalina
        AssignedTo: dev@tomcat.apache.org
        ReportedBy: jsa@silbergrau.com


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).

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

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


Mime
View raw message