IllegalStateException in DistributableSessionManager (WildFly 40 Beta) when invalidating and immediately recreating a session

[Igors Patrejevs]

Hi WildFly community,

  I believe I’ve found a regression or a bug in WildFly 40 Beta related to clustered session management.

  The Issue:
  In a web application marked with <distributable/>, calling HttpSession.invalidate() followed immediately by
  HttpServletRequest.getSession(true) within the same request results in a java.lang.IllegalStateException.

  Environment:
   - WildFly 40 Beta (specifically seeing org.wildfly.clust...@40.0.0.Beta1 and
     org.wildfly.clu...@10.0.1.Final in the stack trace).
   - The application is configured as <distributable/> in web.xml.

  Observed Behavior:
   - The error only occurs when the request arrives with an existing session cookie (i.e., on the second and subsequent
     requests).
   - If there is no session cookie (first request), the logic works fine.
   - If <distributable/> is removed, the logic works perfectly even with cookies.
   - It appears that DistributableSessionManager fails to create a new session because it's in an inconsistent state
     while processing the invalidation of the session associated with the incoming ID.

  Minimal Reproduction Code:

    1 @WebServlet("/test")
    2 public class SessionServlet extends HttpServlet {
    3     @Override
    4     protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException,
      IOException {
    5         HttpSession session = request.getSession(false);
    6         if (session != null) {
    7             session.invalidate();
    8         }
    9         // This call throws IllegalStateException on the second request
   10         HttpSession newSession = request.getSession(true);
   11
   12         response.getWriter().println("New session created: " + newSession.getId());
   13     }
   14 }

  Partial Stack Trace:

   1 java.lang.IllegalStateException
   2     at org.wildfly.clu...@10.0.1.Final//org.wildfly.clustering.function.Runner$1.run(Runner.java:91)
   3     at
     org.wildfly.clu...@10.0.1.Final//org.wildfly.clustering.function.Consumer$1.accept(Consumer.java:198)
   4     at
     org.wildfly.clust...@40.0.0.Beta1//org.wildfly.clustering.web.undertow.session.DistributableSessionM
     anager.getSession(DistributableSessionManager.java:169)
   5     at
     org.wildfly.clust...@40.0.0.Beta1//org.wildfly.clustering.web.undertow.session.DistributableSessionM
     anager.createSession(DistributableSessionManager.java:142)
   6     at
     io.undert...@2.0.0.RC1//io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:953)
   7     at
     io.undert...@2.0.0.RC1//io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.ja
     va:455)

  I have a minimal reproduction Maven project (WAR) ready. Is this a known issue in the 40 Beta clustering
  implementation, or should I proceed with filing a JIRA?

  Best regards,
Igors Patrejevs

[Brian Stansberry]

Hi Igors,

Thanks for reporting this! Paul Ferraro filed https://redhat.atlassian.net/browse/WFLY-21894 today, I believe because he saw your report.

Best regards,

Brian Stansberry

WildFly project lead

[Paul Ferraro]

I tried to reproduce this using the main branch.  It no longer throws an ISE, but there are other issues.

Specifically, Undertow's ServletRequestContext, which references the HttpSession never clears its reference after session invalidation.

I've opened https://redhat.atlassian.net/browse/UNDERTOW-2764 to track this.

This means that the ServletRequestContext continues to references the invalidated session even after a new one is created by the same request.

This is particularly problematic because it means that Undertow never invokes Session.requestDone(...) for the new session.

For non-distributed session, the consequence is minimal - if the recreated session is never accessed again, it will timeout prematurely, i.e. timeout since creation rather than timeout since request completion.

For distributed sessions, the consequence is significant - since the Session.requestDone(...) method is what initiates replication and expiration scheduling.

I'll add a workaround to WildFly until this is properly fixed in Undertow.

[Paul Ferraro]

N.B. WFLY-21894 is only tangentially related - not the root cause of the problem.

[Paul Ferraro]

Fix is here: https://github.com/wildfly/wildfly/pull/20008

[Igors Patrejevs]

Hi Paul, Brian,

  Thank you so much for the incredibly fast response and the fix!

  I would like to clarify that the example I provided (invalidate() followed by getSession(true)) was a
  synthetic case specifically designed for easy reproduction.

  In our real-world environment, we encounter this issue in more natural scenarios, such as:
   1. When a session expires due to a timeout, but the browser sends the old cookie in the next request.
   2. When a session is invalidated in one servlet/request, and a subsequent request with the same ID hits
      another servlet that attempts to create a new session.

  Essentially, the problem seems to be triggered whenever an incoming request carries a "rotten" session ID
  that is already marked as closed or expired in the cluster.

  Again, thank you for the amazing speed in addressing this! We really appreciate it.

  Best regards,

  Igors Patrejevs

среда, 13 мая 2026 г. в 23:00:44 UTC+3, Paul Ferraro: