4 Replies Latest reply on Oct 12, 2009 6:48 PM by Brian Stansberry

    HTTP Session passivation - How to survive server restarts?

    Richard Taylor Newbie

      Note: It was suggested that I move this post to this forum from JBoss Cache Users (the original post was here: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=162299 No content there)

      I'd like to enable HTTP Session passivation so that all active sessions are passivated to disk during a graceful server restart. I'd like users to stay logged in through a server restart (single server). This is especially helpful in a development environment.

      JBoss 5.1.0
      JBoss Cache 3.2.1

      I've read the following and have followed the instructions:
      http://www.jboss.org/community/wiki/HttpSessionPassivationDesign
      http://www.jboss.org/community/wiki/DistributableHttpSessionPassivation

      Session passivation works in the sense that when my specified time limits are hit, sessions are written to disk. However when I gracefully shut down the server, all passivated sessions are deleted from disk.

      In the section describing passivation being triggered by a server shutdown it says:

      If the session is valid, then it's passivated to allow for reconstruction of the session



      This implies either that my sessions are being considered invalid, a configuration issue, or possibly a bug. My HTTP session timeout is 20 minutes, so I should be fine in that regard.

      Relevant configuration:
      From our jboss-web.xml
      <passivation-config>
       <use-session-passivation>true</use-session-passivation>
       <passivation-min-idle-time>-1</passivation-min-idle-time>
       <passivation-max-idle-time>300</passivation-max-idle-time>
      </passivation-config>
      


      From the http session cache section of jboss-cache-manager-jboss-beans:
      <property name="cacheLoaderConfig">
       <bean class="org.jboss.cache.config.CacheLoaderConfig">
       <!-- Do not change these -->
       <property name="passivation">true</property>
       <property name="shared">false</property>
      
       <property name="individualCacheLoaderConfigs">
       <list>
       <bean class="org.jboss.cache.loader.FileCacheLoaderConfig">
       <!-- Where passivated sessions are stored -->
       <property name="location">${jboss.server.data.dir}${/}session2</property>
       <!-- Do not change these -->
       <property name="async">false</property>
       <property name="fetchPersistentState">true</property>
       <property name="purgeOnStartup">true</property>
       <property name="ignoreModifications">false</property>
       <property name="checkCharacterPortability">false</property>
       </bean>
       </list>
       </property>
       </bean>
       </property>
      



      Is there a trick to getting this going? This should be possible, correct?

        • 1. Re: HTTP Session passivation - How to survive server restart
          Brian Stansberry Master

          Good question. Complicated answer.

          First, if you want to try to get this to work, you can disable buddy replication in your JBC config and also update the JBC config's cacheLoaderConfig section:

          <property name="purgeOnStartup">false</property>


          That's "true" by default.

          The issue with reading sessions off the disk at startup is that the persistent-across-server-restart storage for a session is meant to be the other nodes in the cluster, not the disk. If you also start reading sessions off the disk, you run into the potential of having using out-of-date data from the disk in preference to the data transferred from the cluster. This is particularly the case with buddy replictation.

          See https://jira.jboss.org/jira/browse/JBAS-5627, particularly the subtasks under it, for a more in-depth discussion.

          • 2. Re: HTTP Session passivation - How to survive server restart
            Richard Taylor Newbie

            OK, it sounds like this may be ok in a single server dev environment, but doesn't make much sense in an actual/production cluster. What you said makes sense. In theory not all servers are suppose to go down at the same time anyway ;). I had played with the purgeOnStartup but it seemed to lead to other inconsistencies in replication / startup, which is what you hinted at. Thanks, I'll try to use it locally, but will skip it in production.

            • 3. Re: HTTP Session passivation - How to survive server restart
              Richard Taylor Newbie

              I'd just like to report back that 1. disabling Buddy Replication and 2. setting "purgeOnStartup" to false does allow HTTP Sessions to survive server restarts on my local machine. This is handy for various reasons. Thx.

              • 4. Re: HTTP Session passivation - How to survive server restart
                Brian Stansberry Master

                Thanks for confirming that. What you're trying to do is valid; it's just that it requires real caution when used in an actual cluster with production data, so it's not the default.

                That technique won't work if the JBC config has "useRegionBasedMarshalling" set to true. Which in AS 5.1 is only the case for the field-granularity-session-cache, but will probably be the default everywhere in 5.2.

                I bring that up because there's some hard-coded logic that detects useRegionBasedMarshalling=true and deletes the sessions off the disk at webapp undeploy. But thinking about your question has me thinking the "purgeOnStartup" flag could handle that useRegionBasedMarshalling=true use case fine as well, removing the need to have the cleanup be hard coded, and letting people like yourself control the behavior.