[jboss-jira] [JBoss JIRA] (WFLY-6090) Problems with passivation listener ordering cause CoarseSessionPassivationTestCase to fail intermittently with Undertow 1.3.16.Final

Problems with passivation listener ordering cause CoarseSessionPassivationTestCase to fail intermittently with Undertow 1.3.16.Final ------------------------------------------------------------------------------------------------------------------------------------ Key: WFLY-6090 URL: https://issues.jboss.org/browse/WFLY-6090 Project: WildFly Issue Type: Bug Components: Clustering Reporter: Stuart Douglas Assignee: Paul Ferraro The upgrade to Undertow 1.3.16.Final causes this test to fail frequently (but not every time). The change that makes this more frequent was the change to send the response before closing the session. If you are having trouble reproducing this you can add the following code to the bottom of the SessionOperationServlet doGet method to make it 100% reproducible (this should work with any version of Undertow): {code} resp.getOutputStream().close(); try { Thread.sleep(100); } catch (InterruptedException e) { throw new RuntimeException(e); } {code} The underlying problem here is the way the passivation/activation listeners are called. Previously if you did not close the response in the Servlet the session would be closed before the response would be sent, which guaranteed that prePassivate would be called. This also had the side effect that the test would only ever require a single request to see the first session passivating. This is no longer the case, which means the following: - Sometimes session1 has not had its passivation listener called before the session2 request is made - The second session2 request can result in a call to sessionActivated (which makes the test fail). This is especially bogus as there is a chance session2 has not had sessionWillPassivate called yet. The underlying cause of all this is the way listeners are handled in InfinispanSessionManager when persistent is true. Basically: - Requests can cause a session to activate before the passivation listener has been called, resulting in out of order invocations - Multiple concurrent requests to a session will result in multiple activation callbacks, followed by multiple passivation callbacks. Basically at the moment the ordering these events is completely broken.