Immutant
  1. Immutant
  2. IMMUTANT-193

file-store session persistence not working

    Details

    • Type: Bug Bug
    • Status: Closed Closed (View Workflow)
    • Priority: Major Major
    • Resolution: Partially Completed
    • Affects Version/s: 0.7.0
    • Fix Version/s: 0.8.0
    • Labels:
      None
    • Workaround:
      Workaround Exists
    • Workaround Description:
      Hide

      Here's how to make it work: look for the cache-container named web within $IMMUTANT_HOME/jboss/standalone/configuration/standalone-ha.xml. Inside that element is a replicated-cache element. Replace its file-store element with this:

      <file-store preload="true" passivation="false" purge="false"/>
      
      Show
      Here's how to make it work: look for the cache-container named web within $IMMUTANT_HOME/jboss/standalone/configuration/standalone-ha.xml . Inside that element is a replicated-cache element. Replace its file-store element with this: <file-store preload= "true" passivation= "false" purge= "false" />
    • Similar Issues:
      Show 10 results 

      Description

      Based on IRC chat, the expectation is that session should be persisted to disk when an app is redeployed in clustered mode.

      sample immutant/init.clj: (project called "sessiontest")

      (ns immutant.init
        (:require [immutant.messaging :as messaging]
                  [immutant.web :as web]
                  [ring.middleware.session :as ring-session]
                  [immutant.web.session :as session]
                  [immutant.util :as util]))
      
      (defn counter
        [request]
        (let [counter (if-let [counter (-> request :session :counter)]
                        (+ counter 1)
                        1)]
          (println "REQUEST" request)
          {:status 200
           :headers {"Content-Type" "text/html"}
           :body (str "counter is " counter)
           :session {:counter counter}}))
      
      (web/start "/" (ring-session/wrap-session counter
                                  {:store (session/servlet-store)}))
      

      example session:

      $ curl http://localhost:8080/sessiontest
      counter is 1
      $ curl http://localhost:8080/sessiontest
      counter is 1
      $ curl http://localhost:8080/sessiontest -b cookiejar -c cookiejar
      counter is 1
      $ curl http://localhost:8080/sessiontest -b cookiejar -c cookiejar
      counter is 2
      $ curl http://localhost:8080/sessiontest -b cookiejar -c cookiejar
      counter is 3
      $ curl http://localhost:8080/sessiontest -b cookiejar -c cookiejar
      counter is 4

      session is clearly maintained when cookies are provide

      app is redeployed using "lein immutant deploy", log shows nothing saved to disk:

      14:47:03,393 INFO [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-15) ISPN000029: Passivating all entries to disk
      14:47:03,393 INFO [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-15) ISPN000030: Passivated 0 entries in 0 milliseconds

      And session is not maintained

      $ curl http://localhost:8080/sessiontest -b cookiejar -c cookiejar
      counter is 1

        Activity

        Hide
        Jim Crossley
        added a comment -

        <normanrichards> 14:47:07,270 INFO
        [org.infinispan.configuration.cache.EvictionConfigurationBuilder]
        (MSC service thread 1-9) ISPN000152: Passivation configured
        without an eviction policy being selected. Only manually
        evicted entities will be passivated.

        Show
        Jim Crossley
        added a comment - <normanrichards> 14:47:07,270 INFO [org.infinispan.configuration.cache.EvictionConfigurationBuilder] (MSC service thread 1-9) ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
        Hide
        Jim Crossley
        added a comment - - edited

        Here's how to make it work: look for the cache-container named web within $IMMUTANT_HOME/jboss/standalone/configuration/standalone-ha.xml. Inside that element is a replicated-cache element. Replace its file-store element with this:

        <file-store preload="true" passivation="false" purge="false"/>
        

        I'm not sure yet whether to make this the default. The docs for this kind of configuration are either awful or nonexistent, but wrt passivation, I recommend looking at this to better understand that concept: https://docs.jboss.org/author/display/ISPN/Cache+Loaders+and+Stores

        Show
        Jim Crossley
        added a comment - - edited Here's how to make it work: look for the cache-container named web within $IMMUTANT_HOME/jboss/standalone/configuration/standalone-ha.xml . Inside that element is a replicated-cache element. Replace its file-store element with this: <file-store preload= "true" passivation= "false" purge= "false" /> I'm not sure yet whether to make this the default. The docs for this kind of configuration are either awful or nonexistent, but wrt passivation, I recommend looking at this to better understand that concept: https://docs.jboss.org/author/display/ISPN/Cache+Loaders+and+Stores
        Hide
        Jim Crossley
        added a comment -

        The comment/workaround shows how to achieve persistence, but I'm not going to make it default at this time for these reasons:

        1) Sessions are already "persistent" in a cluster because they're replicated, so as long as one peer is up (and web requests are proxied to the cluster), session state persists.

        2) Redeployment implies changes to the app, potentially broken by "old" session data.

        3) There are space/perf costs associated with preloading the session cache from disk, probably negligible in most cases, but I'd want the admin to invoke the workaround himself to avoid surprises.

        Show
        Jim Crossley
        added a comment - The comment/workaround shows how to achieve persistence, but I'm not going to make it default at this time for these reasons: 1) Sessions are already "persistent" in a cluster because they're replicated, so as long as one peer is up (and web requests are proxied to the cluster), session state persists. 2) Redeployment implies changes to the app, potentially broken by "old" session data. 3) There are space/perf costs associated with preloading the session cache from disk, probably negligible in most cases, but I'd want the admin to invoke the workaround himself to avoid surprises.

          People

          • Assignee:
            Jim Crossley
            Reporter:
            Norman Richards
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: