[
http://jira.jboss.com/jira/browse/JBAS-3096?page=all ]
Brian Stansberry closed JBAS-3096.
----------------------------------
Fix Version/s: JBossAS-4.0.5.GA
(was: JBossAS-5.0.0.Beta)
(was: JBossAS-4.0.6.CR1)
Resolution: Done
Fixed in Branch_4_0. Ended up using the Tomcat background thread, as it's the
simplest solution for now.
Add a maxInactiveInterval concept to ClusteredSingleSignOn
----------------------------------------------------------
Key: JBAS-3096
URL:
http://jira.jboss.com/jira/browse/JBAS-3096
Project: JBoss Application Server
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: Web (Tomcat) service, Security, Clustering
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: JBossAS-4.0.5.GA
Original Estimate: 3 days
Remaining Estimate: 3 days
SSOs are currently invalidated when all sessions associated with the SSO are expired.
The problem is webapp undeploy or server shutdown can result in all sessions being
expired, even though the sessions are distributed and can thus be accessed on other
cluster nodes. If the user then fails over to another server, the SSO is gone.
Not invalidating SSOs when all sessions expire can lead to memory leaks -- SSOs that
never can removed from the local and distributed caches.
Idea here is to timestamp the sso when all its sessions are expired, and then some
configurable time later invalidate the sso if no new sessions have been added.
Issues:
1) The TC background thread doesn't call into Valves, so there is no natural thread
to check for "expired" SSOs. I'm considering hijacking the regular TC bg
thread, since it ends up calling into the valve whenever it expires a session. That's
ugly though.
2) Have to make sure that the other cluster nodes know the sso is
"semi-expired" so they can do the expiration check, since often the node where
the sso originally lived has been shut down. This should be simple; just another
TreeCache event to monitor.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira