[ https://issues.jboss.org/browse/WFLY-12815?page=com.atlassian.jira.plugin... ] NUNO GODINHO DE MATOS commented on WFLY-12815: ---------------------------------------------- Hi, Concerning the sample application. Unfortunately I do not have it. The fact is it was not necessary for me to have one, because I was unable to reproduce the issue until I found out what the issue really was. And once i found out what the issue was, my productive application could reproduce the issue any time I wanted it to cause the issue, so there was no point in in spending time doing it. But reproducing the issue on your side should be very simple, as explained in the stack overflow tracker. 1. Make sure you configure your undertow to timeout sessions very quickly (e.g. session termination every 1 minute) 2. Define in the application a session destroyed listner {code:title=SomeSessionListener|borderStyle=solid} @ApplicationScoped public class SomeSessionListener implements HttpSessionListener @Override public void sessionDestroyed(HttpSessionEvent event) {code} 3. Make sure the session Listener when it is handling the even blows up with some application error. I believe it is also important to clarify that the RequestScope is just a minor detail on this issue. I think it is always interesting the fact that from application server to application server, some small fine grained details of do I have the scope in this situation or not always appear. The development APIs are the same but under the hood there are so many small differences between on runtime environment and another, that you always encounter such things ... And then probably these are always aspects that can be refined in future specs to try to ensure that the behavior is more standardized than it currently is. But the main point is not the fact that our session destroyed handling was blowing up because of the lack of the request scope context. This was the problem we had. But I believe the main point here is that the "blowing up" of the "client application code" during this phase is very problematic. Whetehr it is a request scope context not active error, or simply "your application is bugy error and blowing up during this phase". The end result is the same I believe. The main point is that when UNDERTOW is doing its: {code:title=UndertowCleaninupSessions|borderStyle=solid} at io.undertow.servlet.core.SessionListenerBridge.sessionDestroyed(SessionListenerBridge.java:75) at io.undertow.server.session.SessionListeners.sessionDestroyed(SessionListeners.java:61) at io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(InMemorySessionManager.java:586) at io.undertow.server.session.InMemorySessionManager$SessionImpl$2$1.run(InMemorySessionManager.java:393) at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecuto {code} Widlfy taps into this event and activates the SessionScope for the client application. So during session destroyed event we can be playing with the session scoped. But if our code is faulty our code will blow up (it does not matter what causes our code to blow up). And then we have a big problem because this one thread that Undertow used to notify about a session destroyed will now be having stored in ThreadScope state the fact that this HTTPSessionDestructionContext is active. We have poisoned a thread in thread pool by having our code blow up during the session destroyed phase. When this specific thread is used to handle a normal HTTP Request, wildfly will activate the usual SessionContext implementation during the start of the request, and we will end up having a thread that has the traditional HttpSessonContext active (as by design) plus the HttpSessionDestruction context due the client application blow up. And here is where there should be a mechanism to prevent this thing from happening. Probably there should be some sort of fail safe mechanis in wildlfy, before allowing a thread to be used to handle any stort of request, in terms of making sure that no CDI context is allowed to be active at the begining of the request, until the normal flow of procesisng HTTP / EJB requests etc... decide to active the cdi scope. Does this explanation make some sort of sense? -- This message was sent by Atlassian Jira (v7.13.8#713008)