[jboss-jira] [JBoss JIRA] Updated: (JBAS-3096) Add a maxInactiveInterval concept to ClusteredSingleSignOn

[Brian Stansberry (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBAS-3096?page=all ]

Brian Stansberry updated JBAS-3096:
-----------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.CR1)

> 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.6.CR1
>
>   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