[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

[NUNO GODINHO DE MATOS (Jira)]

    [ https://issues.redhat.com/browse/WFLY-12815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14277356#comment-14277356 ] 

NUNO GODINHO DE MATOS commented on WFLY-12815:
----------------------------------------------

Hi,

Many thanks for your advice.

 

So I will take your feedback about it being a very bad idea to let servlet listener to blow up, since it can break the chain of listeners setup by the App Container.

It will probably make sense to make our own basic "top level" listener with an implementation code as simple try catch log exception, with a reference to this issue indicating that breaking a chain of listeners setup by an app server can lead to nasty unforeseen consequences (e.g. the listener chain setup by the app server provider not running to the end).

Hopefully we get no side effects from handling these exceptions since it would be acting  at a layer of code well before any JTA transaction is started or needs to be rolledback. So the DB  / JMS layer should not be corrupted by introducing this new safety-net layer.

 

 

Thanks a lot for the instructions.

I understand that the port cannot be back ported to wildfly 13.

That is totally fine, for wildfly 13 our dirty patch works like a survival kit.

And for a future versions we would be covered by your fix. :)

 

 

Once I get the time to test this fix, I will report back to you.

 

Super, thanks a lot.

 

 

 

 

 

 

> 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: 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-than-one-context-active-for-scope-type-javax-enterp/58960369#58960369
> 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)