Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-18927

[GSS](7.2.z) Session attribute lost issue with the ATTRIBUTE replication-granularity + non-BATCH cache in a failover scenario

XMLWordPrintable

    • +
    • Workaround Exists
    • Hide

      One of the following is sufficient to workaround this issue:

      1. Enable transactions on the distributed-cache. e.g. <transaction mode="BATCH"/>
      2. Use a non-transactional scattered-cache instead of a non-transactional distributed-cache
      Show
      One of the following is sufficient to workaround this issue: Enable transactions on the distributed-cache. e.g. <transaction mode="BATCH"/> Use a non-transactional scattered-cache instead of a non-transactional distributed-cache

      A newly created session attribute after failover is lost in the subsequent session.getAttribute() invocations during the same request processing.

      —

      When a request is routed to the 2nd node in a failover scenario and a new session attribute is generated on the failover node, the newly stored session attribute is lost in the subsequent `session.getAttribute()` invocation during the same request. The subsequent `session.getAttribute()` invocation returns a different session attribute that does not store the expected data but contains data with an initial value.

      Scenario:

      1. Send a request to server1
      A new session is generated, but a session attribute is not yet created in this step.

      2. failover happens and 2nd request is routed to server2 with the above session id.
      A new session attribute is created and set to the session in this step.

      3. The newly created session attribute is not obtained from the subsequent "session.getAttribute()" during the *same* request processing of the step 3.

      This issue happens with the following configurations:

      • A web application has the "ATTRIBUTE" replication granularity in jboss-web.xml
      <?xml version="1.0" encoding="UTF-8"?>
<jboss-web
        version="7.1"
        xmlns="http://www.jboss.com/xml/ns/javaee"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/schema/jbossas/jboss-web_7_1.xsd">
    <replication-config>
        <replication-granularity>ATTRIBUTE</replication-granularity>
    </replication-config>
</jboss-web>

              <subsystem xmlns="urn:jboss:domain:infinispan:7.0">
            ...
            <cache-container name="web" default-cache="dist" module="org.wildfly.clustering.web.infinispan">
                <transport lock-timeout="60000"/>
                <distributed-cache name="dist">
                    <!-- <locking isolation="REPEATABLE_READ"/> -->
                    <!-- <transaction mode="BATCH"/> -->
                    <file-store/>
                </distributed-cache>
            </cache-container>
            ...
        </subsystem>

      You can reproduce the issue locally with the attached reproducer. See also README.md in the reproducer.zip for details.

      It's a simple servlet application that stores Counter object as a session attribute. Also, it repeats "session.getAttribute()" and increment the counter during the one request processing.

      The following is the log message when the issue happens. The ERROR message happens when "session.getAttribute()" does not return the object which stores an expected value. 

      23:13:50,068 INFO  [example.TestServlet] (default task-1) --------------------------------------------------------
23:13:50,070 INFO  [example.TestServlet] (default task-1) ### request uri = /example/test, session id = 8RkKVShBZwYLzLyUkipRZiJJG_SL-akKA_kizqLr
23:13:50,126 INFO  [example.TestServlet] (default task-1) ### session attribute [test] did not exist. create and set with a new object Counter [hashcode = 929940061, value = 0]. 
23:13:50,127 INFO  [example.TestServlet] (default task-1) ### test0: counter value = 0 , hashcode = 929940061
23:13:50,232 INFO  [example.TestServlet] (default task-1) ### test1: counter value = 0 , hashcode = 292552645
23:13:50,232 ERROR [example.TestServlet] (default task-1) ### unexpected counter value!! / actual = 0, expected = 1 
23:13:50,233 INFO  [example.TestServlet] (default task-1) ### test2: counter value = 1 , hashcode = 292552645
23:13:50,234 INFO  [example.TestServlet] (default task-1) ### test3: counter value = 2 , hashcode = 292552645
23:13:50,234 INFO  [example.TestServlet] (default task-1) ### test4: counter value = 3 , hashcode = 292552645
23:13:53,289 INFO  [example.TestServlet] (default task-2) --------------------------------------------------------
23:13:53,290 INFO  [example.TestServlet] (default task-2) ### request uri = /example/test, session id = 8RkKVShBZwYLzLyUkipRZiJJG_SL-akKA_kizqLr
23:13:53,290 INFO  [example.TestServlet] (default task-2) ### test0: counter value = 1 , hashcode = 1471200080
23:13:53,291 ERROR [example.TestServlet] (default task-2) ### unexpected counter value!! / actual = 1, expected = 4 
23:13:53,292 INFO  [example.TestServlet] (default task-2) ### test1: counter value = 2 , hashcode = 1471200080
23:13:53,292 INFO  [example.TestServlet] (default task-2) ### test2: counter value = 3 , hashcode = 1471200080
23:13:53,293 INFO  [example.TestServlet] (default task-2) ### test3: counter value = 4 , hashcode = 1471200080
23:13:53,294 INFO  [example.TestServlet] (default task-2) ### test4: counter value = 5 , hashcode = 1471200080

        1. reproducer.zip
          22 kB
        2. TestServlet2.java
          3 kB

              pferraro@redhat.com Paul Ferraro
              rhn-support-mmiura Masafumi Miura
              Votes:
              0 Vote for this issue
              Watchers:
              11 Start watching this issue

                Created:
                Updated:
                Resolved: