New session attributes do not mutate correctly and when applied on a non-primary owner of a session and backing cache is non-transactional ------------------------------------------------------------------------------------------------------------------------------------------ Key: WFLY-13233 URL: https://issues.redhat.com/browse/WFLY-13233 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 18.0.1.Final, 19.0.0.Beta3 Reporter: Paul Ferraro Assignee: Paul Ferraro Priority: Critical 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 {code} <?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> {code} - `<transaction mode="BATCH"/>` are disabled for the "web" cache in infinispan subsystem (like https://access.redhat.com/solutions/2776221) {code} <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> {code} 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. {code} 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 {code}