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

[Brian Stansberry (JIRA)]

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-3.2.8.SP1, JBossAS-3.2.8 Final, JBossAS-4.0.3 SP1, JBossAS-4.0.3 Final, JBossAS-4.0.2 Final, JBossAS-4.0.1 SP1, JBossAS-4.0.1 Final, JBossAS-3.2.7 Final, JBossAS-3.2.6 Final, JBossAS-3.2.5 Final
            Reporter: Brian Stansberry
         Assigned To: Brian Stansberry
             Fix For: 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