November 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12815) Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304

by NUNO GODINHO DE MATOS (Jira)

NUNO GODINHO DE MATOS created WFLY-12815: -------------------------------------------- Summary: Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 Key: WFLY-12815 URL: https://issues.jboss.org/browse/WFLY-12815 Project: WildFly Issue Type: Bug Components: CDI / Weld Affects Versions: 13.0.0.Final Environment: Environment independent the issue, it is purely a logical problem Reporter: NUNO GODINHO DE MATOS Assignee: manovotn The full description of the problem can be seen in stack overflow. Please consulder the issue: https://stackoverflow.com/questions/58930939/wildflt-13-weld-001304-more-... SUMMARY: (1) Setup you wildfly to have a session timeout of 1 minute - so that you can esaily make your http sessions timeout (2) Program in your WAR application a sessionDestroyed listener that will be broken. In our case whenever the session is timing out, we have some code that explodes in wildfly and not in weblogic because it expected for the RequestScope context to be active, but apparently in wildfly when Undertow to start killing of a session the request scope context is not made active so that caused our session destroyed handling to break (3) Do this sufficient amount of times to corrupted as may threads in the thread pool as possible (4) Now try to interact with your application making use of some session scoped beans . If you travel to ay sort of view that makes use of a session scoped bean that thread will be broken with the exception that multiple session scope context implementation are active. But this exception will only come out and aply if the thread handling the HTTP request is one of the threads that in the past were used by undertow to handle the session timeout. The only threads that have been corrupted forever are those that had a broken sessin timeout Explanation for the issue: - When the session timeout is being orchestrated by underdow, wildfly is activating a special HttpSessionDescrutionContext and making it active. This ACTIVE TRUE/FALSE flag is a ThreadLocal variable. So the activation of the scope context is marked on the thread itself. - When the thread blows up the thread context will remain for as long at the thread lives - in a future request the flag had that thread local variable active already. So when the BeanManagaerImpl is hunting to the one and only active http session context it finds the traditional happy path http session context active plust the DestructionSession context that was activated in a previous call. All of the illustrative stack traces that facilitate the comprehention of the issue are shown in the stack overflow thread. I am of the oppinion that errors like this can happen in the deployed applications. It would not hurt if wildfly would somehow be able to ensure that the thread that hand an explosion in a previous request is not corrupted when it is used to handle new requests. Many thanks for having a look. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12814) PreDestroy method not called by stateful beans with timeout 0

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-12814?page=com.atlassian.jira.plugin... ] Cheng Fang updated WFLY-12814: ------------------------------ Description: When a stateful bean is configured to have timeout value 0, its preDestroy method is not called when removing it. The expected behavior is the bean should timeout and be eligible for removal immediately (since the stateful timeout is 0), and its preDestroy method is called before the bean is removed. The problem seems to be in {{org.jboss.as.ejb3.cache.simple.SimpleCache}}, which removes the bean with 0 timeout value directly, instead of submitting it to {{org.wildfly.clustering.ee.cache.scheduler.LocalScheduler}} for removal. The direct removal does not have all the proper setup for the preDestroy method to be invoked. was:When a stateful bean is configured to have timeout value 0, its preDestroy method is not called when removing it. The expected behavior is the bean should timeout and be eligible for removal immediately (since the stateful timeout is 0), and its preDestroy method is called before the bean is removed. > PreDestroy method not called by stateful beans with timeout 0 > -------------------------------------------------------------- > > Key: WFLY-12814 > URL: https://issues.jboss.org/browse/WFLY-12814 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 18.0.0.Final > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > Fix For: 19.0.0.Beta1 > > > When a stateful bean is configured to have timeout value 0, its preDestroy method is not called when removing it. The expected behavior is the bean should timeout and be eligible for removal immediately (since the stateful timeout is 0), and its preDestroy method is called before the bean is removed. > The problem seems to be in {{org.jboss.as.ejb3.cache.simple.SimpleCache}}, which removes the bean with 0 timeout value directly, instead of submitting it to {{org.wildfly.clustering.ee.cache.scheduler.LocalScheduler}} for removal. The direct removal does not have all the proper setup for the preDestroy method to be invoked. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12814) PreDestroy method not called by stateful beans with timeout 0

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-12814?page=com.atlassian.jira.plugin... ] Cheng Fang updated WFLY-12814: ------------------------------ Description: When a stateful bean is configured to have timeout value 0, its preDestroy method is not called when removing it. The expected behavior is the bean should timeout and be eligible for removal immediately (since the stateful timeout is 0), and its preDestroy method is called before the bean is removed. > PreDestroy method not called by stateful beans with timeout 0 > -------------------------------------------------------------- > > Key: WFLY-12814 > URL: https://issues.jboss.org/browse/WFLY-12814 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 18.0.0.Final > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > Fix For: 19.0.0.Beta1 > > > When a stateful bean is configured to have timeout value 0, its preDestroy method is not called when removing it. The expected behavior is the bean should timeout and be eligible for removal immediately (since the stateful timeout is 0), and its preDestroy method is called before the bean is removed. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12814) PreDestroy method not called by stateful beans with timeout 0

by Cheng Fang (Jira)

Cheng Fang created WFLY-12814: --------------------------------- Summary: PreDestroy method not called by stateful beans with timeout 0 Key: WFLY-12814 URL: https://issues.jboss.org/browse/WFLY-12814 Project: WildFly Issue Type: Bug Components: EJB Affects Versions: 18.0.0.Final Reporter: Cheng Fang Assignee: Cheng Fang -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12814) PreDestroy method not called by stateful beans with timeout 0

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-12814?page=com.atlassian.jira.plugin... ] Cheng Fang updated WFLY-12814: ------------------------------ Fix Version/s: 19.0.0.Beta1 > PreDestroy method not called by stateful beans with timeout 0 > -------------------------------------------------------------- > > Key: WFLY-12814 > URL: https://issues.jboss.org/browse/WFLY-12814 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 18.0.0.Final > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > Fix For: 19.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12614) Duplicated ConstraintViolation message

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-12614?page=com.atlassian.jira.plugin... ] Cheng Fang commented on WFLY-12614: ----------------------------------- Just for a record, we evaluated this issue in EJBCLIENT-357 (EJBClient.isEJBProxy method returns false )when testing an ejb proxy. Basically there is no api to check if a proxy is ejb proxy or cdi proxy or generic proxy, and if one needs to do that, it will depend on implementation. > Duplicated ConstraintViolation message > -------------------------------------- > > Key: WFLY-12614 > URL: https://issues.jboss.org/browse/WFLY-12614 > Project: WildFly > Issue Type: Bug > Components: Bean Validation, REST > Affects Versions: 17.0.1.Final, 18.0.0.Beta1 > Reporter: Robin Schimpf > Assignee: Ronald Sigal > Priority: Major > Attachments: wildfly-bug.zip > > > We currently are upgrading our application from Wildfly 13 to Wildfly 17.0.1 and are receiving duplicated constraint violations in the response of an invalid request. > Interestingly Wildfly 13 also seems to be not behaving correctly on the third request but in another way. There is the violation exception returned in the response instead of the duplicated value Wildfly 17 is returning now. > I also tested this on the currently available Wildfly 18 Beta 1 and the issue is also reproducible. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12697) Upgrade Jackson2 to 2.10.1

by Alessio Soldano (Jira)

[ https://issues.jboss.org/browse/WFLY-12697?page=com.atlassian.jira.plugin... ] Alessio Soldano updated WFLY-12697: ----------------------------------- Summary: Upgrade Jackson2 to 2.10.1 (was: Upgrade Jackson2 to 2.10.0) > Upgrade Jackson2 to 2.10.1 > -------------------------- > > Key: WFLY-12697 > URL: https://issues.jboss.org/browse/WFLY-12697 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Priority: Major > Fix For: 19.0.0.Beta1 > > > https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.10 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-273) Templates at eap-cd-dev branch still referring to image version 17

by Ken Wills (Jira)

[ https://issues.jboss.org/browse/WFWIP-273?page=com.atlassian.jira.plugin.... ] Ken Wills reassigned WFWIP-273: ------------------------------- Assignee: Ken Wills (was: Jeff Mesnil) > Templates at eap-cd-dev branch still referring to image version 17 > ------------------------------------------------------------------ > > Key: WFWIP-273 > URL: https://issues.jboss.org/browse/WFWIP-273 > Project: WildFly WIP > Issue Type: Bug > Components: OpenShift > Reporter: Jan Blizňák > Assignee: Ken Wills > Priority: Critical > > https://github.com/jboss-container-images/jboss-eap-7-openshift-image/tre... > These templates still use image version 17 instead of 18. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12575) Upgrade RESTEasy to 3.9.2.Final

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-12575?page=com.atlassian.jira.plugin... ] James Perkins commented on WFLY-12575: -------------------------------------- Should we close WFLY-12786 as out of date if we do this one? Also how, if at all, does this relate to WFLY-12712? > Upgrade RESTEasy to 3.9.2.Final > ------------------------------- > > Key: WFLY-12575 > URL: https://issues.jboss.org/browse/WFLY-12575 > Project: WildFly > Issue Type: Component Upgrade > Components: REST > Reporter: Ivo Studensky > Assignee: Alessio Soldano > Priority: Major > Labels: downstream_dependency > Fix For: 19.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12575) Upgrade RESTEasy to 3.9.2.Final

by Alessio Soldano (Jira)

[ https://issues.jboss.org/browse/WFLY-12575?page=com.atlassian.jira.plugin... ] Alessio Soldano commented on WFLY-12575: ---------------------------------------- I'm changing this to be the upgrade to 3.9.2.Final, given we're tagging that soon. We'll later create a jira for the 3.10 upgrade. > Upgrade RESTEasy to 3.9.2.Final > ------------------------------- > > Key: WFLY-12575 > URL: https://issues.jboss.org/browse/WFLY-12575 > Project: WildFly > Issue Type: Component Upgrade > Components: REST > Reporter: Ivo Studensky > Assignee: Alessio Soldano > Priority: Major > Labels: downstream_dependency > Fix For: 19.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2019