[JBoss JIRA] (WFLY-12815) Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
by NUNO GODINHO DE MATOS (Jira)
[ https://issues.redhat.com/browse/WFLY-12815?page=com.atlassian.jira.plugi... ]
NUNO GODINHO DE MATOS commented on WFLY-12815:
----------------------------------------------
HI,
Just a final update from my side.
... Had some trouble porting my wilfly 13 standaone.xml domain to wildfly 20 initially.
But fortunately most configuration aspects were working, including the way we do logging and our modules for eclipselink.
In any case, in wildfly 20 I was able to reproduce the issue.
I have uploade under "02" prefix some log files that demonstrate the issue also happening there.
And then what I did was mini hack the module
C:\dev\appserver\wildfly\wildfly-20.0.1.Final\modules\system\layers\base\org\jboss\weld\core\main
And instead of using:
weld-web-3.1.4.Final.jar
I made it use weld-web-3.1.5-SNAPSHOT.jar.
Fortunately here this was not a big adventure like on wildfly 13.
So i was able to test the sanpshot without any problems and without needing to do a full scale replacement of the wildfly core...
The patch fix is definitely working.
I uploaded a log file that demonstrates that the duplicate context was no longer shown.
The only thing I did not understand and did not like, was the fact that the log statement:
if (getSessionDestructionContext().isActive()) {
ServletLogger.LOG.destructionContextLeak(); <----------------- this message did not appear in my log file.
getSessionDestructionContext().deactivate();
}
But the breakpoint
org.jboss.weld.module.web.servlet.HttpContextLifecycle.requestInitialized(HttpServletRequest, ServletContext)
In the method definitely got triggered.
So I have no doubt that the fix is working fine.
The logging part, not so sure.
As for Wildfly 13, I believe we will continue using our hacky patch. But I am happy to know it is gone from the base, since this issue was quite critical and very hard to track down.
Many many thanks.
> Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12815
> URL: https://issues.redhat.com/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: Matěj Novotný
> Priority: Major
> Attachments: 01_snippets_of_code_of_sample_app.7z, 02_issue_fix2_using_weld-web-3.1.5-SNAPSHOT.jar.txt.7z, 02_reproducing_issue_on_wildfly20_before_patching_weld_core_web.7z, Sample_App_To_reproduceBug_001_RollingFileAppender.7z, sourceCodeToSendToWildfly.7z
>
>
> 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)
4 years, 1 month
[JBoss JIRA] (WFLY-12815) Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
by NUNO GODINHO DE MATOS (Jira)
[ https://issues.redhat.com/browse/WFLY-12815?page=com.atlassian.jira.plugi... ]
NUNO GODINHO DE MATOS updated WFLY-12815:
-----------------------------------------
Attachment: 02_issue_fix2_using_weld-web-3.1.5-SNAPSHOT.jar.txt.7z
> Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12815
> URL: https://issues.redhat.com/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: Matěj Novotný
> Priority: Major
> Attachments: 01_snippets_of_code_of_sample_app.7z, 02_issue_fix2_using_weld-web-3.1.5-SNAPSHOT.jar.txt.7z, 02_reproducing_issue_on_wildfly20_before_patching_weld_core_web.7z, Sample_App_To_reproduceBug_001_RollingFileAppender.7z, sourceCodeToSendToWildfly.7z
>
>
> 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)
4 years, 1 month
[JBoss JIRA] (WFLY-12815) Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
by NUNO GODINHO DE MATOS (Jira)
[ https://issues.redhat.com/browse/WFLY-12815?page=com.atlassian.jira.plugi... ]
NUNO GODINHO DE MATOS updated WFLY-12815:
-----------------------------------------
Attachment: 02_reproducing_issue_on_wildfly20_before_patching_weld_core_web.7z
> Wildfly 13 - Thread local state corrupted by deployed application explosion during session timeout leading to WELD-001304 - More than one context active for scope type javax.enterprise.context.SessionScoped
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-12815
> URL: https://issues.redhat.com/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: Matěj Novotný
> Priority: Major
> Attachments: 01_snippets_of_code_of_sample_app.7z, 02_reproducing_issue_on_wildfly20_before_patching_weld_core_web.7z, Sample_App_To_reproduceBug_001_RollingFileAppender.7z, sourceCodeToSendToWildfly.7z
>
>
> 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)
4 years, 1 month
[JBoss JIRA] (WFCORE-5068) Bootable JAR doesn't create install directories
by James Perkins (Jira)
James Perkins created WFCORE-5068:
-------------------------------------
Summary: Bootable JAR doesn't create install directories
Key: WFCORE-5068
URL: https://issues.redhat.com/browse/WFCORE-5068
Project: WildFly Core
Issue Type: Bug
Components: Bootable JAR
Reporter: Jean Francois Denise
Assignee: James Perkins
The issue occurs with --install-dir Bootable JAR option,
In case the first entry to be unzipped is not a directory, the unzip fails because the install dir doesn't exist.
This issue is hidden on some platforms where the first entries are directories, in such case, directories hierarchy is created.
This issue impacts Arquilian container for Bootable JAR that contains a workaround for it.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (DROOLS-5203) Make DMN Validator use generic V&V module for conflicting, misleading, masked and overlapping rows
by Toni Rikkola (Jira)
[ https://issues.redhat.com/browse/DROOLS-5203?page=com.atlassian.jira.plug... ]
Toni Rikkola updated DROOLS-5203:
---------------------------------
Sprint: 2020 Week 13-15 (from Mar 23), 2020 Week 16-18 (from Apr 13), 2020 Week 19-21 (from May 4), 2020 Week 22-24 (from May 25), 2020 Week 25-27 (from Jun 15), 2020 Week 28-30 (from Jul 6) (was: 2020 Week 13-15 (from Mar 23), 2020 Week 16-18 (from Apr 13), 2020 Week 19-21 (from May 4), 2020 Week 22-24 (from May 25), 2020 Week 25-27 (from Jun 15), 2020 Week 28-30 (from Jul 6), 2020 Week 31-33 (from Jul 27))
> Make DMN Validator use generic V&V module for conflicting, misleading, masked and overlapping rows
> --------------------------------------------------------------------------------------------------
>
> Key: DROOLS-5203
> URL: https://issues.redhat.com/browse/DROOLS-5203
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Reporter: Toni Rikkola
> Assignee: Toni Rikkola
> Priority: Major
> Labels: drools-tools
>
> Goal is to merge and reuse the existing generic validator for the issue types in the title. The user should see no difference in the workbench use, but this will help us to reduce reduncancy and improve future V&V coverage for both DMN and DRL at the same time.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month
[JBoss JIRA] (DROOLS-4865) Add i18n reporting for DMN V&V
by Toni Rikkola (Jira)
[ https://issues.redhat.com/browse/DROOLS-4865?page=com.atlassian.jira.plug... ]
Toni Rikkola updated DROOLS-4865:
---------------------------------
Sprint: 2020 Week 07-09 (from Feb 10), 2020 Week 10-12 (from Mar 2), 2020 Week 13-15 (from Mar 23), 2020 Week 16-18 (from Apr 13), 2020 Week 19-21 (from May 4), 2020 Week 22-24 (from May 25), 2020 Week 25-27 (from Jun 15), 2020 Week 28-30 (from Jul 6) (was: 2020 Week 07-09 (from Feb 10), 2020 Week 10-12 (from Mar 2), 2020 Week 13-15 (from Mar 23), 2020 Week 16-18 (from Apr 13), 2020 Week 19-21 (from May 4), 2020 Week 22-24 (from May 25), 2020 Week 25-27 (from Jun 15), 2020 Week 28-30 (from Jul 6), 2020 Week 31-33 (from Jul 27))
> Add i18n reporting for DMN V&V
> ------------------------------
>
> Key: DROOLS-4865
> URL: https://issues.redhat.com/browse/DROOLS-4865
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Reporter: Toni Rikkola
> Assignee: Toni Rikkola
> Priority: Major
> Labels: drools-tools
>
> The current reporting from the shared V&V is showing debug messages that are not meant for user to see and the custom DMN V&V is not i18n.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 1 month