[
https://issues.redhat.com/browse/WFLY-12815?page=com.atlassian.jira.plugi...
]
NUNO GODINHO DE MATOS edited comment on WFLY-12815 at 7/22/20 4:15 AM:
-----------------------------------------------------------------------
Hi,
Just to let you know we have gotten more reports on this issue.
So we are providing to projects experiencing this issue our "hack" patch to fix
the thread local corruption of the thread:
[^sourceCodeToSendToWildfly.7z]
The source code you get there simply does not contain the application server
identification util. I do not think it matters, it is not everybody that needs to deploy
code to more than on application server type.
This listener allows a project to work around the thread local corruption until they find
out how the got the thread corrupted during a session destroyed event.
The goal is always to find out the original "zero ground" exception that
corrupted the wildfly thread local state. Typically it ends up being some new logic that
requires RequestScope to be active during a session destroyed event that needs to be
refactored ...
But for this wildfly issue here, the underlying reason for the corruption should be
irrelevant.
Wildfly base code should make sure a new thread never starts working with any scope
context active.
IT would be good to not need to implement such work arounds, since these hacky listeners
which can stop working from version to verison of wildfly.
was (Author: nuno.godinhomatos):
Hi,
Just to let you know we have gotten more reports on this issue.
So we are providing to projects experiencing this issue our "hack" patch to fix
the thread local corruption of the thread:
[^sourceCodeToSendToWildfly.7z]
I am adding a sketch of the listener class that we use to work-around this problem,
underlying the underlying "reasons" of our blow ups during session desctroyed
are discovered.
IT would be good to not need to implement such work around with these hacky listeners
which can stop working from version to verison of wildfly.
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-...
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)