3 Replies Latest reply on May 23, 2008 1:17 PM by Brian Stansberry

    Session replication - expiration

    George Wilk Newbie

      We have a clustered deployment environment with several nodes replicating HTTP sessions across the cluster. If the values stored in session don't change over period of time, hence there is no replication taking place, what will be the lifespan of replicated sessions on the nodes not being hit?

      Scenario:
      My cluster consists of nodes A, B and C
      Node A receives the original request and stores some values in session.
      Session update on Node A triggers replication of sessions to Nodes B and C
      Subsequent requests do not cause updates to the values stored in session.
      By chance, all of the subsequent requests are sent to Node A, which keeps the http session alive on this node.
      Will the replicated sessions be maintained on Node B and C, even though session expiration period was reached? I guess what I am asking about is whether session replication takes care of keeping replicated sessions alive?

      Thanks in advance,
      ~george

        • 1. Re: Session replication - expiration
          Brian Stansberry Master

          What AS version?

          In 4.0.5 I added a check where if 80% of the session's maxInactiveInterval has passed since last replication, even a read request will cause the session to replicated.

          There was actually a bug in 4.0.5 that that would cause it to replicate much more frequently than that (http://jira.jboss.com/jira/browse/JBAS-4428). That was fixed in 4.2.1.

          I now think the standard 80% is too high. You can control that 80% value by adding a Tomcat context.xml file to your war's WEB-INF dir with a Manager element:

          Context cookies="true" crossContext="true">
           <Manager pathname="" maxUnreplicatedFactor="10"/> <InstanceListener>org.jboss.web.tomcat.security.RunAsListener</InstanceListener>
          
          </Context>


          You can also use a maxUnreplicatedInterval attribute instead of maxUnreplicatedFactor to specify the maximum unreplicated time in ms.

          In AS 5 the same will exist, but I'll also replicate the timestamp of the session if it hasn't been replicated w/in 60 seconds. In AS 5 the timestamp can be independently replicated, so aggressively replicating is less expensive than it is in AS 4.

          Please note that in all these cases, it is a web request that triggers the replication; i.e. there isn't a background thread or something that does it.

          • 2. Re: Session replication - expiration
            George Wilk Newbie

            Hi, Brian.
            We are running AS 4.2.2 GA.

            So, if I understand this correctly, regardless of how the replication trigger is configured once the maxInactiveInterval has passed since the last replication, first subsequent read request will trigger replication. This means, that at a very least we should read some value from session on each request, correct?

            Thanks,
            ~george

            • 3. Re: Session replication - expiration
              Brian Stansberry Master

              You don't need to read an attribute, just need to be sure HttpServletRequest.getSession() is invoked. You should verify, but I think it almost always is without any effort on your part; e.g. by the Tomcat authentication logic if you use container managed security or by populating the standard 'session' variable if you use a jsp.