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

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: 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
    • Fix Version/s: JBossAS-4.0.5.CR1
    • Component/s: Clustering
    • Labels:
      None
    • Estimated Difficulty:
      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.

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                brian.stansberry Brian Stansberry
                Reporter:
                brian.stansberry Brian Stansberry
              • Votes:
                1 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: