Wildfly aggressively expires web sessions

[Ivan L]

Hello All,

My web application is running as a WAR in Wildfy. I have updated Wildfly from 27.0.1.Final to 30.0.1.Final and the users have started to complain that the session is expiring way to quickly, less than 5 minutes of inactivity. 

I have managed to reproduce it a few times when I saw it like this: my app makes a few XHR requests for one user's action and in my case I saw that a few of such requests were successful just a second ago and the next ones already face with an expired sessions. For example, I click refresh in my app and there are these requests that start one after another:

1 - 200

2 - 200

3 - 200

4 - 403  (at this point the session seems to be expired)

5 - 403

Also, I've started to see many records in the log like this:

Jan 27 16:00:18.173 |INF| stdout: Expiring web session gh_XM37qDrs6UICglqJDKnrgj9PhnAMXdqVM8PVc threadName='LocalScheduler - 2' mdc={} ndc=''
Jan 27 16:00:18.214 |INF| stdout: Expiring web session ZUQgX8oS0XayXcV05TQkXxDKOG-17WsJct20SIXU threadName='LocalScheduler - 2' mdc={} ndc=''

I have this session config in my web.xml:

<session-config>

<session-timeout>60</session-timeout>

<cookie-config>

<http-only>true</http-only>

<secure>true</secure>

</cookie-config>

</session-config>

It seems that this code is directly related to my problem:

https://github.com/wildfly/wildfly/blob/ca30775ec7e6de7a7bbed43494cde6875234511f/clustering/web/infinispan/src/main/java/org/wildfly/clustering/web/infinispan/session/SessionExpirationScheduler.java#L56

https://issues.redhat.com/browse/WFLY-18315

Could anybody comment on this and how I could fix this problem?

[Paul Ferraro]

Can you paste your full web.xml and the contents of your distributable-web and infinispan subsystems?

I will try to reproduce this in the meantime.

[Paul Ferraro]

Also, it looks like a System.out snuck into the source code accidentally.

[Paul Ferraro]

Don't be mislead by that log message.

https://github.com/wildfly/wildfly/blob/ca30775ec7e6de7a7bbed43494cde6875234511f/clustering/web/infinispan/src/main/java/org/wildfly/clustering/web/infinispan/session/SessionExpirationScheduler.java#L60

Triggers this method:

https://github.com/wildfly/wildfly/blob/ca30775ec7e6de7a7bbed43494cde6875234511f/clustering/web/infinispan/src/main/java/org/wildfly/clustering/web/infinispan/session/ExpiredSessionRemover.java#L38

where a session will only be invalidated if it is, according to its metedata, expired.

Enable trace logging on org.wildfly.clustering.web.infinispan.session to see the actual expiration log message.

[Ivan L]

Hi Paul, all,

Here are snippets that you asked. I have redacted some my class names in web.xml, everything else is intact. I will now be working to enable the logging as you described and trying to get that log. Thank you for your help.

standalone.xml:

<subsystem xmlns="urn:jboss:domain:distributable-web:4.0" default-session-management="default" default-single-sign-on-management="default">

<infinispan-session-management name="default" cache-container="web" granularity="SESSION">

<primary-owner-affinity/>

</infinispan-session-management>

<infinispan-single-sign-on-management name="default" cache-container="web" cache="sso"/>

<infinispan-routing cache-container="web" cache="routing"/>

</subsystem>

<subsystem xmlns="urn:jboss:domain:infinispan:14.0">

<cache-container name="web" default-cache="dist" marshaller="PROTOSTREAM" modules="org.wildfly.clustering.web.infinispan">

<transport lock-timeout="60000"/>

<replicated-cache name="sso">

<locking isolation="REPEATABLE_READ"/>

<transaction mode="BATCH"/>

<expiration interval="0"/>

</replicated-cache>

<replicated-cache name="routing">

<expiration interval="0"/>

</replicated-cache>

<distributed-cache name="dist">

<locking isolation="READ_COMMITTED"/>

<transaction mode="BATCH"/>

<expiration interval="0"/>

<file-store passivation="true" purge="true"/>

</distributed-cache>

</cache-container>

</subsystem>

web.xml:

<?xml version="1.0" encoding="UTF-8"?>

<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd"

version="4.0">

<distributable/>

<context-param>

<param-name>contextConfigLocation</param-name>

<param-value>/WEB-INF/applicationContext.xml</param-value>

</context-param>

<listener>

<listener-class> org.springframework.web.context.ContextLoaderListener</listener-class>

</listener>

<servlet>

<servlet-name>spring-web</servlet-name>

<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>

<init-param>

<param-name>contextConfigLocation</param-name>

<param-value></param-value>

</init-param>

<load-on-startup>1</load-on-startup>

</servlet>

<servlet-mapping>

<servlet-name>spring-web</servlet-name>

<url-pattern></url-pattern>

<url-pattern>/login</url-pattern>

</servlet-mapping>

<servlet>

<servlet-name>SpringApplication</servlet-name>

<servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>

<init-param>

<param-name>jakarta.ws.rs.Application</param-name>

<param-value>com.example.Application</param-value>

</init-param>

<load-on-startup>1</load-on-startup>

</servlet>

<servlet-mapping>

<servlet-name>SpringApplication</servlet-name>

<url-pattern>/api/*</url-pattern>

</servlet-mapping>

<servlet>

<servlet-name>ApiApplication</servlet-name>

<servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>

<init-param>

<param-name>jakarta.ws.rs.Application</param-name>

<param-value>com.example.ApiApplication</param-value>

</init-param>

<load-on-startup>1</load-on-startup>

</servlet>

<servlet-mapping>

<servlet-name>ApiApplication</servlet-name>

<url-pattern>/svc/rs/*</url-pattern>

</servlet-mapping>

<filter>

<filter-name>springSecurityFilterChain</filter-name>

<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>

</filter>

<filter-mapping>

<filter-name>springSecurityFilterChain</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

<session-config>

<session-timeout>60</session-timeout>

<cookie-config>

<http-only>true</http-only>

<secure>true</secure>

</cookie-config>

</session-config>

<welcome-file-list>

<welcome-file>index.html</welcome-file>

</welcome-file-list>

<mime-mapping>

<extension>js</extension>

<mime-type>application/javascript</mime-type>

</mime-mapping>

</web-app>

jboss-web.xml:

<?xml version="1.0" encoding="UTF-8"?>

<jboss-web version="14.0" xmlns="http://www.jboss.com/xml/ns/javaee"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/schema/jbossas/jboss-web_14_1.xsd">

<context-root>/</context-root>

</jboss-web>

jboss-deployment-structure.xml:

<?xml version="1.0" encoding="UTF-8"?>

<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:jboss:deployment-structure:1.2 https://raw.githubusercontent.com/wildfly/wildfly-core/master/server/src/main/resources/schema/jboss-deployment-structure-1_2.xsd">

<deployment>

<dependencies>

<module name="com.oracle" export="true"/>

<module name="org.postgresql" export="true"/>

</dependencies>

<exclusions>

</exclusions>

<exclude-subsystems>

</exclude-subsystems>

</deployment>

</jboss-deployment-structure>

[Ivan L]

Hi Paul,

I did not see any log record for aforementioned logger, but for this logger 'org.wildfly.clustering.web.infinispan' I saw this and it shows that the session has expired too quickly, you can even see the Wildfly started log message.

17:38:30,672 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 30.0.1.Final (WildFly Core 22.0.2.Final) started in 37892ms - Started 468 of 544 services (216 services are lazy, passive or on-demand) - Server configuration file in use: standalone.xml
17:38:45,637 TRACE [org.wildfly.clustering.web.infinispan] (default task-1) Session e05W6qKJwqQXLYF3bq6Jj0-Tg3TYBFCPhJ-jqhcw not found
17:38:45,637 TRACE [org.wildfly.clustering.web.infinispan] (default task-2) Session e05W6qKJwqQXLYF3bq6Jj0-Tg3TYBFCPhJ-jqhcw not found
17:38:45,637 TRACE [org.wildfly.clustering.web.infinispan] (default task-3) Session e05W6qKJwqQXLYF3bq6Jj0-Tg3TYBFCPhJ-jqhcw not found
17:38:45,644 TRACE [org.wildfly.clustering.web.infinispan] (default task-3) Session e05W6qKJwqQXLYF3bq6Jj0-Tg3TYBFCPhJ-jqhcw not found
17:38:45,644 TRACE [org.wildfly.clustering.web.infinispan] (default task-2) Session e05W6qKJwqQXLYF3bq6Jj0-Tg3TYBFCPhJ-jqhcw not found
17:38:45,644 TRACE [org.wildfly.clustering.web.infinispan] (default task-1) Session e05W6qKJwqQXLYF3bq6Jj0-Tg3TYBFCPhJ-jqhcw not found
17:38:45,671 TRACE [org.wildfly.clustering.web.infinispan] (default task-1) Session e05W6qKJwqQXLYF3bq6Jj0-Tg3TYBFCPhJ-jqhcw not found
17:38:45,671 TRACE [org.wildfly.clustering.web.infinispan] (default task-2) Session e05W6qKJwqQXLYF3bq6Jj0-Tg3TYBFCPhJ-jqhcw not found
17:38:45,671 TRACE [org.wildfly.clustering.web.infinispan] (default task-3) Session e05W6qKJwqQXLYF3bq6Jj0-Tg3TYBFCPhJ-jqhcw not found
17:38:47,952 TRACE [org.wildfly.clustering.web.infinispan] (default task-3) Session e05W6qKJwqQXLYF3bq6Jj0-Tg3TYBFCPhJ-jqhcw not found
17:38:47,953 TRACE [org.wildfly.clustering.web.infinispan] (default task-3) Session e05W6qKJwqQXLYF3bq6Jj0-Tg3TYBFCPhJ-jqhcw not found
17:38:47,960 TRACE [org.wildfly.clustering.web.infinispan] (default task-3) Session e05W6qKJwqQXLYF3bq6Jj0-Tg3TYBFCPhJ-jqhcw not found
17:40:20,897 TRACE [org.wildfly.clustering.web.infinispan] (default task-7) Session rAMTz1AYQrC8SM6omN-VW24yxVXUdbGJsJNsV07V was found, but has expired
17:40:20,902 TRACE [org.wildfly.clustering.web.infinispan] (default task-4) Session rAMTz1AYQrC8SM6omN-VW24yxVXUdbGJsJNsV07V was found, but has expired
17:40:20,902 TRACE [org.wildfly.clustering.web.infinispan] (default task-8) Session rAMTz1AYQrC8SM6omN-VW24yxVXUdbGJsJNsV07V was found, but has expired
17:40:20,912 TRACE [org.wildfly.clustering.web.infinispan] (default task-7) Session rAMTz1AYQrC8SM6omN-VW24yxVXUdbGJsJNsV07V not found
17:40:20,919 TRACE [org.wildfly.clustering.web.infinispan] (default task-1) Session rAMTz1AYQrC8SM6omN-VW24yxVXUdbGJsJNsV07V not found
17:40:20,919 TRACE [org.wildfly.clustering.web.infinispan] (default task-10) Session rAMTz1AYQrC8SM6omN-VW24yxVXUdbGJsJNsV07V not found
17:40:20,919 TRACE [org.wildfly.clustering.web.infinispan] (default task-6) Session rAMTz1AYQrC8SM6omN-VW24yxVXUdbGJsJNsV07V not found

[Paul Ferraro]

I just realized that your original message mentioned the use of XMLHttpRequests.  I would highly suggest using a non-transactional cache for this use case.

e.g.

        <distributed-cache name="dist">

            <expiration interval="0"/>
            <file-store passivation="true" purge="true"/>
        </distributed-cache>

On Tuesday, January 30, 2024 at 4:22:45 PM UTC-5 Ivan L wrote:

[Paul Ferraro]

Thanks for the additional info.  Your web.xml indicates the use of Spring Session.

org.springframework.web.context.ContextLoaderListener installs a servlet filter that wraps the HttpServletRequest such that calls to getSession(...) are handled by Spring rather than WildFly.

It is unclear to me where and how your application creates any sessions that would be known to WildFly's session manager.

Which Spring Session implementation are you using and what exactly is your use case for it?

N.B. I have documented the known issues/limitations with Spring Session here:

https://github.com/wildfly-clustering/wildfly-clustering-spring-session?tab=readme-ov-file#notes

 

Paul

[Ivan L]

Hi Paul,

No, I am positive this is not true. I do use Spring Framework, Spring Web. I DO NOT use Spring session.

The listener org.springframework.web.context.ContextLoaderListener create Spring context and in some cases (when Spring Session is used) perhaps it might create that filter but not in my case. Moreover, if I see the session in debug breakpoint 'request.getSession(false)', I see it like this:

io.undertow.servlet.spec.HttpSessionImpl@d507c3bf

[Paul Ferraro]

I see.  Can you post the code handling your XMLHttpRequests?  Perhaps there is an issue with the async handling that might be preventing the session from recording its last access?

[Ivan L]

Hi Paul,

Thanks for your help. I can't really see how I can provide any useful snippet of the code, it's just Spring and Jersey JAX-RS code. I don't use async in the server side. There is javascript SPA which can issue many XHR requests in parallel and some of them that started early might finish long after latter requests, I mean there is no particular order because some of them take more time than the others.

I am doing my research and I have noticed something interesting. I have set up a breakpoint and here is how session entry looks like in this method org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager.findSession(String):

DefaultSessionMetaDataEntry { created = 2024-02-01T09:32:23.896Z, timeout = PT1H, last-access-start = 2024-02-01T09:48:32.296Z, last-access-end = 2024-02-01T09:48:33.296Z }={SPRING_SECURITY_CONTEXT=SecurityContextImpl [Authentication=OAuth2AuthenticationToken [Principal=xxx, Credentials=[PROTECTED], Authenticated=true, Details=WebAuthenticationDetails [RemoteIpAddress=127.0.0.1, SessionId=vd8TQuExPYvHJyx7OJN07W2NGroNojg7ffsh5SHb], Granted Authorities=[OIDC_USER, SCOPE_openid, SCOPE_email, ROLE_User, SCOPE_User.Read, SCOPE_profile]]]}

And what is interesting is that last-access-start and last-access-end behave very weirdly. I mean that while last-access-starts seems OK, last-access-end sometimes appears in the past (which I believe must never happen). Sometimes, it goes beyond minutes, for example it might appear like  2024-02-01T06:15:34.408Z and in this case isExpired() returns true:

DefaultSessionMetaDataEntry { created = 2024-02-01T09:32:23.896Z, timeout = PT1H, last-access-start = 2024-02-01T09:42:03.408Z, last-access-end = 2024-02-01T09:45:34.408Z } <-- 43 mins on the clock

DefaultSessionMetaDataEntry { created = 2024-02-01T09:32:23.896Z, timeout = PT1H, last-access-start = 2024-02-01T09:45:14.386Z, last-access-end = 2024-02-01T09:45:15.386Z }

DefaultSessionMetaDataEntry { created = 2024-02-01T09:32:23.896Z, timeout = PT1H, last-access-start = 2024-02-01T09:46:08.467Z, last-access-end = 2024-02-01T09:49:40.467Z } <-- 46 mins on the clock

DefaultSessionMetaDataEntry { created = 2024-02-01T09:32:23.896Z, timeout = PT1H, last-access-start = 2024-02-01T09:46:36.249Z, last-access-end = 2024-02-01T09:46:37.249Z } <-- 47 mins on the clock

DefaultSessionMetaDataEntry { created = 2024-02-01T09:32:23.896Z, timeout = PT1H, last-access-start = 2024-02-01T09:48:13.302Z, last-access-end = 2024-02-01T09:48:14.302Z } <-- 48 mins on the clock

I have not found the cause for this. Perhaps, you could point me in the right direction. I would be grateful for your tips.

Regards,

Ivan

[Ivan L]

Follow-up for my previous message, here is an example of an "expired" session:

DefaultSessionMetaDataEntry { created = 2024-02-01T11:34:13.557Z, timeout = PT1H, last-access-start = 2024-02-01T09:49:29.849Z, last-access-end = 2024-02-01T08:58:44.849Z }

[Paul Ferraro]

Quick question: Your application is distributable - is your application running on multiple processes?  I just want to rule out the possibility of clock sync issues.

There were quite a few changes to the session metadata implementation since WF27.  To summarize:

* Where WF27 stored session metadata within 2 Infinispan cache entries, WF30 uses a single entry

* Where WF27 applies session metadata changes by overwriting the previous entry via Map.put(...), WF30 applies deltas via Map.compute(...)

In terms of how the session meta data is stored:

* "created" is stored as an Instant, but with millisecond precision

* "timeout" is stored as a Duration, but with second precision

* "last-access-start" (i.e. the timestamp of the start of the previous access, as reported by HttpSession.getLastAccessTime()) is stored as a Duration since creation, with millisecond precision

* "last-access-end" (i.e. the timestamp of the end of the previous access, used for expiration processing), is stored as a Duration since last-access-start, but with second precision (usually 1 second)

In a given request:

* "created" is never updated

* "timeout" is only updated (via delta) if modified via HttpSession.setMaxInactiveInterval(...)

* "last-access-start" will apply a small duration every request (effectively the number of milliseconds between requests)

* "last-access-end" would only update when the duration of a request is more or less time (in seconds) than the previous request

The logic behind this should be covered by extensive unit tests, but your observations do suggest a bug somewhere.  I will take a closer look today.

Paul

[Paul Ferraro]

Hmmm.  So, in this instance, the last-access-start is earlier than the created timestamp? _and_ the last-access-end is earlier than last-access-start?  That is very odd.

Do you have machine timestamps for these log messages as well so I can correlate them?

[Ivan L]

Hi Paul,

> Quick question: Your application is distributable - is your application running on multiple processes?  I just want to rule out the possibility of clock sync issues.

Yes, my app is distributable but it does not normally run in a cluster. I use this feature mainly for no-downtime: app rolling updates, k8s node updates. So when the problem occurs, there is only one instance. Moreover, I see this problem when I just run wildfly locally in my development laptop.

> Hmmm.  So, in this instance, the last-access-start is earlier than the created timestamp? _and_ the last-access-end is earlier than last-access-start?  That is very odd.

Do you have machine timestamps for these log messages as well so I can correlate them?

Unfortunately, this is not a log. I was debugging and looking at the clock on the breakpoint, you can see it to the right of <--

[Paul Ferraro]

I think I managed to reproduce the issue.  I should have a fix submitted soon (to be included in WF 31.0.1.Final).

[Paul Ferraro]

*sigh* My reproducer was buggy and once fixed no longer reproduces the problem.  Still investigating...

[Paul Ferraro]

OK - I've reproduced the issue now.  Will keep you updated with my findings.

[Paul Ferraro]

Strike that - my reproducer criteria was not correct.

Technically, the request immediately following the request that created a session can have a last access start time that is earlier than the session creation time.

However, for subsequent requests, the last access start time will always be later.

Investigation continues...

[Ivan L]

Thank you, Paul.

I have not managed to reproduce that with my simplified reproducer too. Can only reproduce it with the real app. Here are some more debug catches of the expiration.

DefaultSessionMetaDataEntry { created = 2024-02-01T21:13:24.490Z, timeout = PT1H, last-access-start = 2024-02-02T02:35:12.683Z, last-access-end = 2024-02-01T19:58:25.683Z }

did not look at the wall clock this time (but this is a curious case I think)

DefaultSessionMetaDataEntry { created = 2024-02-01T21:21:33.849Z, timeout = PT1H, last-access-start = 2024-02-01T16:50:27.098Z, last-access-end = 2024-02-01T16:50:32.098Z }
wall clock: 21:24Z

DefaultSessionMetaDataEntry { created = 2024-02-01T21:31:51.621Z, timeout = PT1H, last-access-start = 2024-02-01T20:44:56.012Z, last-access-end = 2024-02-01T19:24:09.012Z }
wall clock: 21:33Z

DefaultSessionMetaDataEntry { created = 2024-02-01T21:34:55.226Z, timeout = PT1H, last-access-start = 2024-02-01T19:01:57.154Z, last-access-end = 2024-02-01T19:41:44.154Z }
wall clock: 21:36Z

Wall clock means the actual time when it hit the breakpoint.

[Paul Ferraro]

Question: are you able to reproduce this problem if you disable transactions in your Infinispan cache?

[Ivan L]

Hi Paul,

Today I have tried my test case for 28.0.1.Final, 29.0.1.Final and 30.0.1.Final. The first two did not have the problem, I was testing them for a few hours. When I again tested for 30.0.1.Final, it did not take me much time to reproduce the problem. Certainly, taking the intermittent nature of the problem into account, it could be in the previous versions too but just did not happen for me this time. However, as I said, for 30.0.1.Final it manifested itself pretty quickly.

[Ivan L]

> Question: are you able to reproduce this problem if you disable transactions in your Infinispan cache?

Yes, I used the snipped you had provided and the problem was still there. However, I am testing it now and cannot reproduce it again. I am not sure how it's possible but cannot reproduce it with this:

        <subsystem xmlns="urn:jboss:domain:infinispan:14.0">
            <cache-container name="web" default-cache="dist" marshaller="PROTOSTREAM" modules="org.wildfly.clustering.web.infinispan">
                <transport lock-timeout="60000"/>
                <replicated-cache name="sso">
                    <locking isolation="REPEATABLE_READ"/>
                    <transaction mode="BATCH"/>
                    <expiration interval="0"/>
                </replicated-cache>
                <replicated-cache name="routing">
                    <expiration interval="0"/>
                </replicated-cache>
                <distributed-cache name="dist">

                    <expiration interval="0"/>
                    <file-store passivation="true" purge="true"/>
                </distributed-cache>
            </cache-container>
        </subsystem>

[Ivan L]

Hi Paul,

Just checking. Have you been able to reproduce my problem?

[Paul Ferraro]

Sorry - I have not been able to reproduce this yet.

Is it possible that the aggressively expiring sessions were passivated on shutdown via 27.0.1.Final, then activated on startup using 30.0.1.Final? and maybe that's why you aren't seeing it any longer?

[Ivan L]

Hi Paul,

I am thinking I am not seeing the problem anymore because I have removed this snippet (as you suggested I try that):

<locking isolation="READ_COMMITTED"/>

<transaction mode="BATCH"/>

As for the passivated session, I think this is out of the question as I am running Wildfly in a stateless container and moreover, the new sessions are created and expire during the single run, it's not that the problem is after a restart only.

[Paul Ferraro]

That suggests to me that something is interfering with the normal lifecycle of the session.

In WildFly, session context is shared across multiple concurrent threads, where the last thread to complete will close it (replicating/persisting changes).  This includes both session attribute modifications and metadata changes.

However, sessions with an active shared context should never expire, since they are removed from scheduling upon first access, and only rescheduled for expiration upon closing by the last accessing thread.  This _should_ prevent even persistent access exceeding the maxInactiveInterval to cause a session to expire prematurely.  I have since added tests to explicitly validate this scenario, as this was one of my concerns from our discussion above.

The only case where we do not use a shared session context for threads is for transactional caches with REPEATABLE_READ isolation, where only 1 thread will have exclusive access to the session for both reads and writes.

Transactional caches with READ_COMMITTED isolation will allow concurrent reads by multiple threads until the first thread needs to write, requiring exclusive access.  However, because only the last thread accessing the shared session context will ever write to the session, all other threads _should_ have committed their transactions with no effective changes.

As I write this, however, I don't think our tests cover this specific configuration with that access pattern very thoroughly, so I'm hoping further testing will be able to reproduce the problem.

To be honest, the cumulative optimizations for non-transactional caches should avoid the need for most users to ever both with a transactional cache.  So this would be my recommendation even w/out the premature expiration issue.

The only reason this configuration remains in our default configuration is to satisfy the first sentence of section 7.7.2 of the servlet specification:

https://jakarta.ee/specifications/servlet/6.0/jakarta-servlet-spec-6.0#distributed-environments

Paul

[Ivan L]

Hi Paul,

I am sorry I did not respond the last time. Thanks for the explanation and your attention.

I just want to let you know that I am now on 33.0.0.Final and I accidentally reintroduced those locking and transaction elements in configuration during Wildfly upgrade and immediately got an incident ticket from a user about the premature session expiration. Nothing new here, I just got a reminder that there is an issue in there.

Thanks again,

Ivan