[jboss-jira] [JBoss JIRA] Reopened: (JBAS-3545) HASessionState state transfer incorrect for replicated sessions

[Brian Stansberry (JIRA)]

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

Brian Stansberry reopened JBAS-3545:
------------------------------------

             

> HASessionState state transfer incorrect for replicated sessions
> ---------------------------------------------------------------
>
>                 Key: JBAS-3545
>                 URL: http://jira.jboss.com/jira/browse/JBAS-3545
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Clustering
>    Affects Versions: JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-3.2.6 Final, JBossAS-4.0.2 Final, JBossAS-3.2.5 Final, JBossAS-4.0.1 SP1, JBossAS-4.0.3 Final, JBossAS-4.0.3 SP1, JBossAS-3.2.8 Final, JBossAS-3.2.8.SP1, JBossAS-4.0.4.GA
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-3.2.8.SP2, JBossAS-4.0.5.CR1
>
>
> When HASessionStateImpl prepares state for a state transfer, it uses a timestamp check to see whether a bean is overaged before including it in the state.  If the bean is overaged it removes it from its replicated cache.  (Note that this is a separate and distinct process from the standard SFSB passivation and removal process.)
> This algorithm is broken for sessions that are not active on the node preparing the state transfer for two reasons:
> 1) The transient field used to store the modification timestamp (in PackagedSessionImpl) is initialized as part of its declaration:
> protected transient long lastModificationTimeInVM = System.currentTimeMillis ();
> This means the value will not be properly initialized when PackagedSessionImpl is deserialized, as is explained at http://forum.java.sun.com/thread.jspa?threadID=584981&messageID=3002515.
> 2) The lastModificationTimeInVM field is also not updated in the update() method, which is the method that gets called when state updates are replicated from another node.
> The effect of this is that when a state transfer is prepared, all remote beans will be removed from the replicated cache of the preparing node.  At a minimum this means the bean won't be included in the state transfer; it may have other insidious effects on the preparing node as well.
> Fix is to initialize the transient field in the constructor and readObject() and to update it in the update() method.

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