When running JBoss EAP 7.4+ with Oracle Commerce (ATG), there is an IllegalStateException from JBoss/Wildfly code when invalidating a session:

java.lang.IllegalStateException
at org.wildfly.clustering.web.undertow.session.SimpleSessionConfig.clearSession(SimpleSessionConfig.java:47)
at org.wildfly.clustering.web.undertow.session.DistributableSession.invalidate(DistributableSession.java:282)
at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:198) [undertow-servlet-2.2.19.SP2-redhat-00001-jbeap-24198.jar:2.2.19.SP2-redhat-00001]
at atg.userprofiling.email.TemplateInvoker$TemplateSession.endSession(TemplateInvoker.java:993) [_DPS_slib_sclasses.jar:]
at atg.userprofiling.email.TemplateEmailSender.createMessage(TemplateEmailSender.java:2420) [_DPS_slib_sclasses.jar:]

The Oracle Commerce (ATG) here has executed a "loopback" request back to the same app server instance and established a new session. Our code then retrieves that session object and uses this new session to render an email template using JSPs. When this is done, we call invalidate() on the session object from our code to invalidate this session as it shouldn't stick around (if the customer's site is sending a lot of emails like this, leaving the sessions around to timeout could have a significant impact).

To give an example of the use case, a customer might submit an order on the site in the context of their session and then the code would use this feature to render an order confirmation email using a separate session just for rendering the email.

This code has been working like this for 20+ years and works with other application servers (e.g. WebLogic and WebSphere) and has worked with past versions of JBoss (e.g. EAP 7.2.x and earlier).

Looking at the Wildfly code here, it seems that SimpleSessionConfig is hard-coded to throw an IllegalStateException if clearSession() is called. Tracing further in DistributableSession, it seems like the problem relates to the logic of getSessionEntry(). The comments indicate that the entry is non-null in the context of a request (presumably a request that is associated with the particular session) and presumably this entry points to a SessionConfig implementation that allows clearSession() to be called. However, outside the context of a request associated with this session (which is when we are calling invalidate), the entry is null at first and initialized as seen in getSessionEntry() and uses SimpleSessionConfig which throws the IllegalStateException when invalidate() is called. We can further confirm the JBoss behavior here in requestDone() which set entry to null.

The documentation for javax.servlet.http.HttpSession.invalidate() gives no indication that this call should not work unless the session is already invalidated, so it is a violation of the spec to have invalidate() fail simply because the call is done outside the scope of a request associated with that session.

The fix here seems simple, to just change SimpleSessionConfig.clearSession() to be a no-op instead of throwing an IllegalStateException.

We also found in following DistributeSession.invalidate() that when this exception occurs, there is no further "work" in DistributableSession to be done for invalidating the session. So, the workaround from our perspective is to simply catch the IllegalStateException and ignore it so it does not break our code flow. However, this does have the risk of ignoring a legitimate IllegalStateException in some cases.