[JBoss JIRA] (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
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13233?page=com.atlassian.jira.plugi... ]
Paul Ferraro updated WFLY-13233:
--------------------------------
Summary: 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 (was: Session attributes do not mutate correctly and when created on a non-primary owner of a session and backing cache is non-transactional)
> 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
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 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}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-5157) [DMN Designer] Monaco editor: Scrolling inside LiteralExpression editor breaks users ability to input data
by Michael Anstis (Jira)
[ https://issues.redhat.com/browse/DROOLS-5157?page=com.atlassian.jira.plug... ]
Michael Anstis updated DROOLS-5157:
-----------------------------------
Summary: [DMN Designer] Monaco editor: Scrolling inside LiteralExpression editor breaks users ability to input data (was: Scrolling inside descision expression editor brokes user ability to put any data)
> [DMN Designer] Monaco editor: Scrolling inside LiteralExpression editor breaks users ability to input data
> ----------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5157
> URL: https://issues.redhat.com/browse/DROOLS-5157
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.35.0.Final
> Reporter: Anna Dupliak
> Assignee: Guilherme Gomes
> Priority: Major
> Labels: drools-tools
> Attachments: scroll.webm
>
>
> When User edit multy-linear Literal expression in some Descision
> And scrolls down
> Then focus looses
> And User could not put any data to any edit field
> See: [^scroll.webm]
> Workaround:
> Logout and login back
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-5155) Regression Issue: compile failed when use a decision table as Context Entry value
by xiaodong zhang (Jira)
[ https://issues.redhat.com/browse/DROOLS-5155?page=com.atlassian.jira.plug... ]
xiaodong zhang commented on DROOLS-5155:
----------------------------------------
Thanks Michael and Matteo for the quick response.
By the way, this issue will be fixed in 7.34 or 7.35 ?
> Regression Issue: compile failed when use a decision table as Context Entry value
> ---------------------------------------------------------------------------------
>
> Key: DROOLS-5155
> URL: https://issues.redhat.com/browse/DROOLS-5155
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.33.0.Final
> Reporter: xiaodong zhang
> Assignee: Matteo Mortari
> Priority: Blocker
> Attachments: 11.png, aaa.dmn
>
>
> Regression Issue: compile failed when use a decision table as Context Entry value.
> The error message is :
> DMN: Validation of the DMN Model cannot be performed because of some runtime exception 'org.kie.dmn.model.v1_2.TContextEntry cannot be cast to org.kie.dmn.model.api.NamedElement'. (DMN Validation stopped on failed validation for some DMN Model)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13233) Session attributes do not mutate correctly and when created on a non-primary owner of a session and backing cache is non-transactional
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13233?page=com.atlassian.jira.plugi... ]
Paul Ferraro updated WFLY-13233:
--------------------------------
Summary: Session attributes do not mutate correctly and when created on a non-primary owner of a session and backing cache is non-transactional (was: New session attributes do not mutate correctly and when applied on a non-primary owner of a session and backing cache is non-transactional)
> Session attributes do not mutate correctly and when created 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}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13233) New session attributes do not mutate correctly and when applied on a non-primary owner of a session and backing cache is non-transactional
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13233?page=com.atlassian.jira.plugi... ]
Paul Ferraro updated WFLY-13233:
--------------------------------
Summary: New session attributes do not mutate correctly and when applied on a non-primary owner of a session and backing cache is non-transactional (was: Session attributes do not mutate correctly and when applied on a non-primary owner of a session and backing cache is non-transactional)
> 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}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13233) Session attributes do not mutate correctly and when applied on a non-primary owner of a session and backing cache is non-transactional
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13233?page=com.atlassian.jira.plugi... ]
Paul Ferraro moved JBEAP-18935 to WFLY-13233:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-13233 (was: JBEAP-18935)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
(was: Clustering)
Affects Version/s: 19.0.0.Beta3
18.0.1.Final
(was: 7.2.6.GA)
> 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: 19.0.0.Beta3, 18.0.1.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Major
>
> 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}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (WFLY-13233) Session attributes do not mutate correctly and when applied on a non-primary owner of a session and backing cache is non-transactional
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/WFLY-13233?page=com.atlassian.jira.plugi... ]
Paul Ferraro updated WFLY-13233:
--------------------------------
Priority: Critical (was: Major)
> 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}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (DROOLS-5157) Scrolling inside descision expression editor brokes user ability to put any data
by Anna Dupliak (Jira)
[ https://issues.redhat.com/browse/DROOLS-5157?page=com.atlassian.jira.plug... ]
Anna Dupliak moved RHPAM-2801 to DROOLS-5157:
---------------------------------------------
Project: Drools (was: Red Hat Process Automation Manager)
Key: DROOLS-5157 (was: RHPAM-2801)
Workflow: GIT Pull Request workflow (was: CDW with docs v1)
Docs QE Status: NEW
Component/s: DMN Editor
(was: Business Central)
Affects Version/s: 7.35.0.Final
(was: 7.7.0.GA)
QE Status: NEW
> Scrolling inside descision expression editor brokes user ability to put any data
> --------------------------------------------------------------------------------
>
> Key: DROOLS-5157
> URL: https://issues.redhat.com/browse/DROOLS-5157
> Project: Drools
> Issue Type: Bug
> Components: DMN Editor
> Affects Versions: 7.35.0.Final
> Reporter: Anna Dupliak
> Assignee: Kris Verlaenen
> Priority: Major
> Labels: drools-tools
> Attachments: scroll.webm
>
>
> When User edit multy-linear Literal expression in some Descision
> And scrolls down
> Then focus looses
> And User could not put any data to any edit field
> See: [^scroll.webm]
> Workaround:
> Logout and login back
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months