[jboss-jira] [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

[ https://issues.redhat.com/browse/WFLY-12815?page=com.atlassian.jira.plugi... ] NUNO GODINHO DE MATOS edited comment on WFLY-12815 at 7/28/20 9:02 AM: ----------------------------------------------------------------------- Hi, I would Just like to let you know I have dome some small modifications to a sample application to try to make it reproduce the issue discussed here.   Uploadd: I have uploaded a log file Sample_App_To_reproduceBug_001_RollingFileAppender.7z from my C:\dev\appserver\wildfly\wildfly-13.0.0.Final\user_projects\domains\WM6Maint-3925_SampleApp_Postgres\log.    Where you can see the sample application can be used to make the issue happen. I have also uploaded on a different zip, the 01_snippets_of_code_of_sample_app.7z  the interesting parts of the code of the sample app to make the issue happen.    I am not uploading the full sample app because I would need to remove content from it... and there is not much point to it. The code uploaded there can easily be bundled into any WAR file.    The thing to remember is that for this issue, you want to change the standalone.xml to have the servlet container default looking like this: servlet-container name="default" default-session-timeout="1"   this helps with reproduce the issue, since after 1 minute wildfly will kill of the session. Having a breakpoint in: web.wildfly12815.WFLY12815SessionListener.sessionDestroyed(HttpSessionEvent)   Also helps, since this will allow you to login several sessions and have the session destroyed stop in your breakpoint thus corrupting multiple threads.     Testing the patch: I will now try to build weld core and check if with it the issue stops being reproducible. I will probably not follow the instruction on doing a FULL scale replacement of the weld core. I need to continue working with Wildfly 13 for now the way it is vanilla,  to experience the same sort of issues of projects using wildfly 13. So i want o be perfectly in control of what code gets changed or not in my installation... What I believe I will do is to build the weld code, and then grab the specific classes you have modified in your pull request. And they I will go the "hacker" way and extract the weld code from my wildfly 13 and sneak in their your new classes. IF I am lucky they are still compatible and not significant changes have gone into those two files since widlfly 13. If I am not lucky I would need to replaye the full weld core...  But I will do that as a last resort.     By the way yo get your pull request I actually needed to do: git fetch origin refs/pull/2005/head:pull/2005   The command on the instruction above seemed to not work.   Many thanks was (Author: nuno.godinhomatos): Hi, Hi, I would Just like to let you know I have dome some small modifications to a sample application to try to make it reproduce the issue discussed here.   Uploadd: I have uploaded a log file Sample_App_To_reproduceBug_001_RollingFileAppender.7z from my C:\dev\appserver\wildfly\wildfly-13.0.0.Final\user_projects\domains\WM6Maint-3925_SampleApp_Postgres\log.    Where you can see the sample application can be used to make the issue happen. I have also uploaded on a different zip, the 01_snippets_of_code_of_sample_app.7z  the interesting parts of the code of the sample app to make the issue happen.    I am not uploading the full sample app because I would need to remove content from it... and there is not much point to it. The code uploaded there can easily be bundled into any WAR file.    The thing to remember is that for this issue, you want to change the standalone.xml to have the servlet container default looking like this: servlet-container name="default" default-session-timeout="1"   this helps with reproduce the issue, since after 1 minute wildfly will kill of the session. Having a breakpoint in: web.wildfly12815.WFLY12815SessionListener.sessionDestroyed(HttpSessionEvent)   Also helps, since this will allow you to login several sessions and have the session destroyed stop in your breakpoint thus corrupting multiple threads.     Testing the patch: I will now try to build weld core and check if with it the issue stops being reproducible. I will probably not follow the instruction on doing a FULL scale replacement of the weld core. I need to continue working with Wildfly 13 for now the way it is vanilla,  to experience the same sort of issues of projects using wildfly 13. So i want o be perfectly in control of what code gets changed or not in my installation... What I believe I will do is to build the weld code, and then grab the specific classes you have modified in your pull request. And they I will go the "hacker" way and extract the weld code from my wildfly 13 and sneak in their your new classes. IF I am lucky they are still compatible and not significant changes have gone into those two files since widlfly 13. If I am not lucky I would need to replaye the full weld core...  But I will do that as a last resort.     By the way yo get your pull request I actually needed to do: git fetch origin refs/pull/2005/head:pull/2005   The command on the instruction above seemed to not work.   Many thanks -- This message was sent by Atlassian Jira (v7.13.8#713008)