Loading...

Details

Type: Bug
Resolution: Done
Priority: Major
Fix Version/s: 7.2.8.CR1, 7.2.8.GA
Affects Version/s: 7.2.6.GA
Component/s: Clustering
Labels:
- test_included

QE Test Coverage:
+
Target Release:

7.2.z.GA
Workaround:

Workaround Exists
Workaround Description:
Hide

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
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
Git Pull Request:
https://github.com/jbossas/jboss-eap7/pull/3419

SFDC Cases Counter:
SFDC Cases Links:

Description

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>

`<transaction mode="BATCH"/>` are disabled for the "web" cache in infinispan subsystem (like https://access.redhat.com/solutions/2776221)

        <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

Attachments

- Sort By Name
- Sort By Date
- Ascending
- Descending
- Thumbnails
- List
- Download All

reproducer.zip
22 kB
2020/03/11 12:53 PM
TestServlet2.java
3 kB
2020/03/13 8:43 AM

Issue Links

clones

JBEAP-18951 [GSS](7.3.z) Object returned by HttpSession.getAttribute(...) following a previous setAttribute(...), not mutating correctly using ATTRIBUTE granularity when cache is non-transactional.

Verified

is cloned by

WFLY-13233 Session attributes do not mutate correctly and when created on a non-primary owner of a session and backing distributed/replicated cache is non-transactional

Closed

links to

KCS#4952271

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

Details

Description

Attachments

Attachments

Issue Links

Activity

People

Dates