[jboss-jira] [JBoss JIRA] Closed: (JBAS-5404) Updated session maxInactiveInterval not respected on backup nodes

Brian Stansberry (JIRA) jira-events at lists.jboss.org
Wed May 7 11:49:22 EDT 2008


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

Brian Stansberry closed JBAS-5404.
----------------------------------

    Resolution: Done

> Updated session maxInactiveInterval not respected on backup nodes
> -----------------------------------------------------------------
>
>                 Key: JBAS-5404
>                 URL: http://jira.jboss.com/jira/browse/JBAS-5404
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service, Clustering
>    Affects Versions: JBossAS-5.0.0.Beta4, JBossAS-4.2.2.GA, JBossAS-4.2.1.GA, JBossAS-4.2.0.GA
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>            Priority: Minor
>             Fix For: JBossAS-5.0.0.CR1
>
>
> The algorithm for evicting backup copies of sessions from the distributed cache uses the session timeout value from web.xml to evaluate whether a backup copy of a session is overage. It does not take into consideration the fact that an individual session may have had its maxInterval changed.
> The session is expired appropriately on the node where it is active; it's just that the backup copy doesn't get flushed from the cache as promptly.  If there is a failover after the maxInterval has elapsed, JBossWeb will see that and expire the session; it won't provide it to a client.
> Fixing this requires adding a mechanism to make the CacheListener aware when an imcoming replicated session has had its maxInterval changed.  In 4.x, the session is an opaque object (MarshalledValue for which the CacheListener lacks the appropriate classloader) so a fix in 4.x would require passing the maxInterval as an attribute in the JBC node. Checking for this would be highly non-performant.
> In AS 5 I want to make the session more transparent, plus the JBC 2.x API provides the CacheListener with a lot more information about what events are happening. So a better fix is possible there.

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

        



More information about the jboss-jira mailing list