Uploaded image for project: 'Application Server 3  4  5 and 6'
  1. Application Server 3 4 5 and 6
  2. JBAS-3545

HASessionState state transfer incorrect for replicated sessions

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • JBossAS-4.0.5.CR1
    • JBossAS-3.2.5 Final, JBossAS-3.2.6 Final, JBossAS-3.2.7 Final, JBossAS-4.0.1 Final, JBossAS-4.0.1 SP1, JBossAS-4.0.2 Final, 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
    • Clustering
    • None
    • Low

    Description

      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.

      Attachments

        Activity

          People

            bstansbe@redhat.com Brian Stansberry
            bstansbe@redhat.com Brian Stansberry
            Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: