You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@shiro.apache.org by "aschwarte10 (via GitHub)" <gi...@apache.org> on 2026/01/08 23:18:10 UTC
[D] [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue) [shiro]
GitHub user aschwarte10 created a discussion: [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue)
### Search before asking
- [x] I had searched in the [issues, **including closed issues**](https://github.com/apache/shiro/issues?q=is%3Aissue) and found no similar issues.
### Environment
Hi all,
in this ticket we want to share information about a potential concurrency issue in Shiro's DefaultWebSessionManager and open a discussion.
In our application we are using Shiro as the Security Framework together with Pac4j. We recently received issue reports about unexpected session expirations at random intervals.
Our technical team followed up and was able to reproduce the behavior with a specific HTTP workload against our application, basically firing a high number of requests and at some point it occurs.
We are only seeing the session expiration issue in ARM64 environments, i.e. we have never faced such errors on Intel or AM64 architectures so far.
Some technical notes:
- seems to happen only im ARM64 environments. We did a bit of research, and found that memory caching and the cache association to the CPU is different between Intel and ARM64.
- the issue happens under more heavy HTTP workloads
- if that is relevant, we are using Jetty 12.0.x (with Jakarta 10) and a Java 25 runtime environment
- for reproducing, we ran our application on an AWS EC2 instance with al2023-ami-2023.9.20251208.0-kernel-6.1-arm64 as base AMI
Our solution in our application is to switch to the ServletContainerSessionManager
As Shiro is a widely used framework, we are curious if the session expiration issue also occurred to others and also what the cause can be.
Please let us know if additional information is required.
### Shiro version
2.0.5
(happens also in 2.0.6)
### What was the actual outcome?
The error expresses with the following exception trace:
```
jakarta.servlet.ServletException: Filtered request failed. (edited)
Caused by: org.apache.shiro.session.ExpiredSessionException: Session with id [561d940e-1155-42fd-8b36-b2378511cd30] has expired. Last access time: 12/8/25, 3:07 PM. Current time: 12/8/25, 3:07 PM. Session timeout is set to 1800 seconds (30 minutes)
at org.apache.shiro.session.mgt.SimpleSession.validate(SimpleSession.java:297) ~[shiro-core-2.0.5]
```
Note that when we face the exception the "last access time" is always equal to the "current time".
### What was the expected outcome?
No unexpected ession expiration behavior.
### How to reproduce
We have a JMeter workload running a high number of requests (with concurrency) using the same session. At some point our workload starts to fail.
### Debug logs
_No response_
GitHub link: https://github.com/apache/shiro/discussions/2447
----
This is an automatically sent email for issues@shiro.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@shiro.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@shiro.apache.org
For additional commands, e-mail: issues-help@shiro.apache.org
Re: [D] [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue) [shiro]
Posted by "aschwarte10 (via GitHub)" <gi...@apache.org>.
GitHub user aschwarte10 added a comment to the discussion: [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue)
Actually, I am really curious to understand, whether we are doing something wrong in our application (which might well be), or whether there exists really some nasty concurrency issue deep inside.
Note that we are using Shiro/Pac4J already for several years in our application - and only now start seeing this, after some of our AWS cloud based users switch to ARM instances.
GitHub link: https://github.com/apache/shiro/discussions/2447#discussioncomment-15455463
----
This is an automatically sent email for issues@shiro.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@shiro.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@shiro.apache.org
For additional commands, e-mail: issues-help@shiro.apache.org
Re: [D] [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue) [shiro]
Posted by "aschwarte10 (via GitHub)" <gi...@apache.org>.
GitHub user aschwarte10 added a comment to the discussion: [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue)
Hi @lprimak ,
do you mean a `org.apache.shiro.session.SessionListener`?
If I remember correctly we have done this, however, the exception (at least in one control flow path) was thrown prior to reaching the session listener (i.e. the session listener was not called). I can try once more during today, if I can get a stacktrace from the session listener.
GitHub link: https://github.com/apache/shiro/discussions/2447#discussioncomment-15472446
----
This is an automatically sent email for issues@shiro.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@shiro.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@shiro.apache.org
For additional commands, e-mail: issues-help@shiro.apache.org
Re: [D] [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue) [shiro]
Posted by "lprimak (via GitHub)" <gi...@apache.org>.
GitHub user lprimak closed the discussion with a comment: [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue)
Hi, Andreas,
Unfortunately, without an easy-to-follow reproducer, there is not much else Shiro team can do here.
If your internal team does find the issue, and it turns out to be inside Shiro, we are more than happy to accept
any contributions, or a PR.
Otherwise, [Commercial Support](https://shiro.apache.org/commercial-support.html) is an available option.
I will close this discussion as there is little else actionable left to do on the Shiro side.
Please feel free to re-open if you have any updates, reproducer, etc.
GitHub link: https://github.com/apache/shiro/discussions/2447#discussioncomment-15849983
----
This is an automatically sent email for issues@shiro.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@shiro.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@shiro.apache.org
For additional commands, e-mail: issues-help@shiro.apache.org
Re: [D] [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue) [shiro]
Posted by "lprimak (via GitHub)" <gi...@apache.org>.
GitHub user lprimak added a comment to the discussion: [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue)
Thank you for your report.
I have converted this into a discussion since there is not (yet) actionable.
Is there any chance to narrow this down? It's really difficult to figure out where to go from here.
Perhaps a thread dump, etc?
GitHub link: https://github.com/apache/shiro/discussions/2447#discussioncomment-15449651
----
This is an automatically sent email for issues@shiro.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@shiro.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@shiro.apache.org
For additional commands, e-mail: issues-help@shiro.apache.org
Re: [D] [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue) [shiro]
Posted by "aschwarte10 (via GitHub)" <gi...@apache.org>.
GitHub user aschwarte10 added a comment to the discussion: [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue)
Thanks for the heads up.
> I emailed you offline, did you by any chance notice those messages?
Actually I have not seen the messages. Checking right away.
No, my inbox of the github account only shows the notifications about this discussion, and that the ticket was moved. Also spam does not contain a message from you. I will send you a personal message with my work email address.
GitHub link: https://github.com/apache/shiro/discussions/2447#discussioncomment-15551012
----
This is an automatically sent email for issues@shiro.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@shiro.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@shiro.apache.org
For additional commands, e-mail: issues-help@shiro.apache.org
Re: [D] [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue) [shiro]
Posted by "aschwarte10 (via GitHub)" <gi...@apache.org>.
GitHub user aschwarte10 edited a comment on the discussion: [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue)
We have tried out different CacheManagers, and also see the expiring session behavior with `MemoryConstrainedCacheManager`
A full stack trace (where the same `ExpiredSessionException` is caught in a slightly different place):
```
2026-01-09 14:25:28,635 ERROR [qtp343856911-40] org.apache.shiro.web.servlet.AbstractShiroFilter - session.touch() method invocation has failed. Unable to update the corresponding session's last access time based on the incoming request.
org.apache.shiro.session.ExpiredSessionException: Session with id [b3f97259-42bf-4e98-9472-7e4fa35054a4] has expired. Last access time: 1/9/26, 2:25 PM. Current time: 1/9/26, 2:25 PM. Session timeout is set to 1800 seconds (30 minutes)
at org.apache.shiro.session.mgt.SimpleSession.validate(SimpleSession.java:297)
at org.apache.shiro.session.mgt.AbstractValidatingSessionManager.doValidate(AbstractValidatingSessionManager.java:192)
at org.apache.shiro.session.mgt.AbstractValidatingSessionManager.validate(AbstractValidatingSessionManager.java:141)
at org.apache.shiro.session.mgt.AbstractValidatingSessionManager.doGetSession(AbstractValidatingSessionManager.java:118)
at org.apache.shiro.session.mgt.AbstractNativeSessionManager.lookupSession(AbstractNativeSessionManager.java:149)
at org.apache.shiro.session.mgt.AbstractNativeSessionManager.lookupRequiredSession(AbstractNativeSessionManager.java:153)
at org.apache.shiro.session.mgt.AbstractNativeSessionManager.touch(AbstractNativeSessionManager.java:232)
at org.apache.shiro.session.mgt.DelegatingSession.touch(DelegatingSession.java:120)
at org.apache.shiro.session.ProxiedSession.touch(ProxiedSession.java:100)
at org.apache.shiro.web.servlet.AbstractShiroFilter.updateSessionLastAccessTime(AbstractShiroFilter.java:330)
at org.apache.shiro.web.servlet.AbstractShiroFilter.lambda$doFilterInternal$0(AbstractShiroFilter.java:377)
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:91)
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:84)
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:389)
at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:376)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:156)
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1594)
at com.COMPANYREDACTED.servlet.filter.ErrorLoggingFilter.doFilter(ErrorLoggingFilter.java:55)
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1594)
at org.eclipse.jetty.ee10.servlet.ServletHandler$MappedServlet.handle(ServletHandler.java:1555)
at org.eclipse.jetty.ee10.servlet.ServletChannel.dispatch(ServletChannel.java:822)
at org.eclipse.jetty.ee10.servlet.ServletChannel.handle(ServletChannel.java:438)
at org.eclipse.jetty.ee10.servlet.ServletHandler.handle(ServletHandler.java:470)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:575)
at org.eclipse.jetty.ee10.servlet.SessionHandler.handle(SessionHandler.java:717)
at org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:1102)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:181)
at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:611)
at org.eclipse.jetty.server.Server.handle(Server.java:182)
at org.eclipse.jetty.server.internal.HttpChannelState$HandlerInvoker.run(HttpChannelState.java:721)
at org.eclipse.jetty.server.internal.HttpConnection.onFillable(HttpConnection.java:416)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:322)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:492)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.epcRunTask(AdaptiveExecutionStrategy.java:428)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:401)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:255)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.run(AdaptiveExecutionStrategy.java:204)
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:311)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:981)
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1211)
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1166)
at java.base/java.lang.Thread.run(Thread.java:1474)
```
Once such exception is visible in our logs, the user session is gone.
Note that this happens on "random" times - in my JMeter workload I have seen it after seconds, but also only after 6 minutes. So this indicates some kind of race condition.
Notes:
- I have never seen / reproduced this exception in an Intel / AMD64 environment (also not when running the same JMeter workload)
- When switching to the servlet container based session manager, I so far have never witnessed the exception
GitHub link: https://github.com/apache/shiro/discussions/2447#discussioncomment-15455435
----
This is an automatically sent email for issues@shiro.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@shiro.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@shiro.apache.org
For additional commands, e-mail: issues-help@shiro.apache.org
Re: [D] [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue) [shiro]
Posted by "aschwarte10 (via GitHub)" <gi...@apache.org>.
GitHub user aschwarte10 added a comment to the discussion: [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue)
I now managed to get a trace (incl stacktraces) for the relevant session events (create, stop, expired) and the exception.
Maybe this gives some further inights
<details>
<summary>Click to expand logs</summary>
```
2026-01-12 10:10:20,562 INFO [qtp343856911-47] Session started: 2faa7154-53c4-4cc2-a84d-2dc417424f07
....
2026-01-12 10:12:12,412 INFO [qtp343856911-248] Session stopped: 2faa7154-53c4-4cc2-a84d-2dc417424f07
2026-01-12 10:12:12,412 TRACE [qtp343856911-248] Stack:
java.lang.Exception
at com.COMPANYNAME.security.SessionListeneer$1.onStop(...)
at org.apache.shiro.session.mgt.AbstractNativeSessionManager.notifyStop(AbstractNativeSessionManager.java:202)
at org.apache.shiro.session.mgt.AbstractValidatingSessionManager.onInvalidation(AbstractValidatingSessionManager.java:184)
at org.apache.shiro.web.session.mgt.DefaultWebSessionManager.onInvalidation(DefaultWebSessionManager.java:299)
at org.apache.shiro.session.mgt.AbstractValidatingSessionManager.validate(AbstractValidatingSessionManager.java:151)
at org.apache.shiro.session.mgt.AbstractValidatingSessionManager.doGetSession(AbstractValidatingSessionManager.java:118)
at org.apache.shiro.session.mgt.AbstractNativeSessionManager.lookupSession(AbstractNativeSessionManager.java:149)
at org.apache.shiro.session.mgt.AbstractNativeSessionManager.lookupRequiredSession(AbstractNativeSessionManager.java:153)
at org.apache.shiro.session.mgt.AbstractNativeSessionManager.getAttribute(AbstractNativeSessionManager.java:250)
at org.apache.shiro.session.mgt.DelegatingSession.getAttribute(DelegatingSession.java:141)
at org.apache.shiro.session.ProxiedSession.getAttribute(ProxiedSession.java:121)
at org.apache.shiro.subject.support.DelegatingSubject.getRunAsPrincipalsStack(DelegatingSubject.java:476)
at org.apache.shiro.subject.support.DelegatingSubject.getPrincipals(DelegatingSubject.java:159)
at org.apache.shiro.subject.support.DelegatingSubject.getPrincipal(DelegatingSubject.java:155)
at ...
at com.COMPANYNNAME.servlet.RedactedServlet.doPost(..)
at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:547)
at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:614)
at org.eclipse.jetty.ee10.servlet.ServletHolder$NotAsync.service(ServletHolder.java:1385)
at org.eclipse.jetty.ee10.servlet.ServletHolder.handle(ServletHolder.java:751)
at org.eclipse.jetty.ee10.servlet.ServletHandler$ChainEnd.doFilter(ServletHandler.java:1622)
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1594)
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1594)
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1594)
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1594)
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1594)
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1594)
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1594)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:65)
at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:109)
at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:138)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:156)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:70)
at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:109)
at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:138)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:156)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:70)
at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:463)
at org.apache.shiro.web.servlet.AbstractShiroFilter.lambda$doFilterInternal$0(AbstractShiroFilter.java:378)
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:91)
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:84)
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:389)
at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:376)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:156)
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1594)
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1594)
at org.eclipse.jetty.ee10.servlet.ServletHandler$MappedServlet.handle(ServletHandler.java:1555)
at org.eclipse.jetty.ee10.servlet.ServletChannel.dispatch(ServletChannel.java:822)
at org.eclipse.jetty.ee10.servlet.ServletChannel.handle(ServletChannel.java:438)
at org.eclipse.jetty.ee10.servlet.ServletHandler.handle(ServletHandler.java:470)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:575)
at org.eclipse.jetty.ee10.servlet.SessionHandler.handle(SessionHandler.java:717)
at org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:1102)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:181)
at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:611)
at org.eclipse.jetty.server.Server.handle(Server.java:182)
at org.eclipse.jetty.server.internal.HttpChannelState$HandlerInvoker.run(HttpChannelState.java:721)
at org.eclipse.jetty.server.internal.HttpConnection.onFillable(HttpConnection.java:416)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:322)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:492)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.epcRunTask(AdaptiveExecutionStrategy.java:428)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:401)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:255)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.run(AdaptiveExecutionStrategy.java:204)
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:311)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:981)
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1211)
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1166)
at java.base/java.lang.Thread.run(Thread.java:1474)
2026-01-12 10:12:12,414 INFO [qtp343856911-256] Session expired: 2faa7154-53c4-4cc2-a84d-2dc417424f07
2026-01-12 10:12:12,414 TRACE [qtp343856911-256] Stack:
java.lang.Exception
at com.COMPANYNAME.security.SessionListeneer.onExpiration(...)
at org.apache.shiro.session.mgt.AbstractNativeSessionManager.notifyExpiration(AbstractNativeSessionManager.java:209)
at org.apache.shiro.session.mgt.AbstractValidatingSessionManager.onExpiration(AbstractValidatingSessionManager.java:163)
at org.apache.shiro.web.session.mgt.DefaultWebSessionManager.onExpiration(DefaultWebSessionManager.java:293)
at org.apache.shiro.session.mgt.AbstractValidatingSessionManager.validate(AbstractValidatingSessionManager.java:144)
at org.apache.shiro.session.mgt.AbstractValidatingSessionManager.doGetSession(AbstractValidatingSessionManager.java:118)
at org.apache.shiro.session.mgt.AbstractNativeSessionManager.lookupSession(AbstractNativeSessionManager.java:149)
at org.apache.shiro.session.mgt.AbstractNativeSessionManager.lookupRequiredSession(AbstractNativeSessionManager.java:153)
at org.apache.shiro.session.mgt.AbstractNativeSessionManager.touch(AbstractNativeSessionManager.java:232)
at org.apache.shiro.session.mgt.DelegatingSession.touch(DelegatingSession.java:120)
at org.apache.shiro.session.ProxiedSession.touch(ProxiedSession.java:100)
at org.apache.shiro.web.servlet.AbstractShiroFilter.updateSessionLastAccessTime(AbstractShiroFilter.java:330)
at org.apache.shiro.web.servlet.AbstractShiroFilter.lambda$doFilterInternal$0(AbstractShiroFilter.java:377)
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:91)
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:84)
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:389)
at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:376)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:156)
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1594)
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1594)
at org.eclipse.jetty.ee10.servlet.ServletHandler$MappedServlet.handle(ServletHandler.java:1555)
at org.eclipse.jetty.ee10.servlet.ServletChannel.dispatch(ServletChannel.java:822)
at org.eclipse.jetty.ee10.servlet.ServletChannel.handle(ServletChannel.java:438)
at org.eclipse.jetty.ee10.servlet.ServletHandler.handle(ServletHandler.java:470)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:575)
at org.eclipse.jetty.ee10.servlet.SessionHandler.handle(SessionHandler.java:717)
at org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:1102)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:181)
at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:611)
at org.eclipse.jetty.server.Server.handle(Server.java:182)
at org.eclipse.jetty.server.internal.HttpChannelState$HandlerInvoker.run(HttpChannelState.java:721)
at org.eclipse.jetty.server.internal.HttpConnection.onFillable(HttpConnection.java:416)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:322)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:492)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.epcRunTask(AdaptiveExecutionStrategy.java:428)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:401)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:255)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.run(AdaptiveExecutionStrategy.java:204)
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:311)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:981)
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1211)
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1166)
at java.base/java.lang.Thread.run(Thread.java:1474)
2026-01-12 10:12:12,415 ERROR [qtp343856911-256] org.apache.shiro.web.servlet.AbstractShiroFilter - session.touch() method invocation has failed. Unable to update the corresponding session's last access time based on the incoming request.
org.apache.shiro.session.ExpiredSessionException: Session with id [2faa7154-53c4-4cc2-a84d-2dc417424f07] has expired. Last access time: 1/12/26, 10:12 AM. Current time: 1/12/26, 10:12 AM. Session timeout is set to 1800 seconds (30 minutes)
at org.apache.shiro.session.mgt.SimpleSession.validate(SimpleSession.java:297)
at org.apache.shiro.session.mgt.AbstractValidatingSessionManager.doValidate(AbstractValidatingSessionManager.java:192)
at org.apache.shiro.session.mgt.AbstractValidatingSessionManager.validate(AbstractValidatingSessionManager.java:141)
at org.apache.shiro.session.mgt.AbstractValidatingSessionManager.doGetSession(AbstractValidatingSessionManager.java:118)
at org.apache.shiro.session.mgt.AbstractNativeSessionManager.lookupSession(AbstractNativeSessionManager.java:149)
at org.apache.shiro.session.mgt.AbstractNativeSessionManager.lookupRequiredSession(AbstractNativeSessionManager.java:153)
at org.apache.shiro.session.mgt.AbstractNativeSessionManager.touch(AbstractNativeSessionManager.java:232)
at org.apache.shiro.session.mgt.DelegatingSession.touch(DelegatingSession.java:120)
at org.apache.shiro.session.ProxiedSession.touch(ProxiedSession.java:100)
at org.apache.shiro.web.servlet.AbstractShiroFilter.updateSessionLastAccessTime(AbstractShiroFilter.java:330)
at org.apache.shiro.web.servlet.AbstractShiroFilter.lambda$doFilterInternal$0(AbstractShiroFilter.java:377)
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:91)
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:84)
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:389)
at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:376)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:156)
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1594)
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1594)
at org.eclipse.jetty.ee10.servlet.ServletHandler$MappedServlet.handle(ServletHandler.java:1555)
at org.eclipse.jetty.ee10.servlet.ServletChannel.dispatch(ServletChannel.java:822)
at org.eclipse.jetty.ee10.servlet.ServletChannel.handle(ServletChannel.java:438)
at org.eclipse.jetty.ee10.servlet.ServletHandler.handle(ServletHandler.java:470)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:575)
at org.eclipse.jetty.ee10.servlet.SessionHandler.handle(SessionHandler.java:717)
at org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:1102)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:181)
at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:611)
at org.eclipse.jetty.server.Server.handle(Server.java:182)
at org.eclipse.jetty.server.internal.HttpChannelState$HandlerInvoker.run(HttpChannelState.java:721)
at org.eclipse.jetty.server.internal.HttpConnection.onFillable(HttpConnection.java:416)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:322)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:492)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.epcRunTask(AdaptiveExecutionStrategy.java:428)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:401)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:255)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.run(AdaptiveExecutionStrategy.java:204)
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:311)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:981)
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1211)
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1166)
at java.base/java.lang.Thread.run(Thread.java:1474)
```
</details>
GitHub link: https://github.com/apache/shiro/discussions/2447#discussioncomment-15474880
----
This is an automatically sent email for issues@shiro.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@shiro.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@shiro.apache.org
For additional commands, e-mail: issues-help@shiro.apache.org
Re: [D] [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue) [shiro]
Posted by "lprimak (via GitHub)" <gi...@apache.org>.
GitHub user lprimak added a comment to the discussion: [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue)
Just wanted to know if you received my email, thanks!
GitHub link: https://github.com/apache/shiro/discussions/2447#discussioncomment-15562006
----
This is an automatically sent email for issues@shiro.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@shiro.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@shiro.apache.org
For additional commands, e-mail: issues-help@shiro.apache.org
Re: [D] [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue) [shiro]
Posted by "lprimak (via GitHub)" <gi...@apache.org>.
GitHub user lprimak added a comment to the discussion: [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue)
Any luck developing a reproducer?
GitHub link: https://github.com/apache/shiro/discussions/2447#discussioncomment-15722162
----
This is an automatically sent email for issues@shiro.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@shiro.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@shiro.apache.org
For additional commands, e-mail: issues-help@shiro.apache.org
Re: [D] [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue) [shiro]
Posted by "aschwarte10 (via GitHub)" <gi...@apache.org>.
GitHub user aschwarte10 edited a comment on the discussion: [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue)
Hi @lprimak ,
do you mean a `org.apache.shiro.session.SessionListener`?
If I remember correctly we have done this, however, the exception (at least in one control flow path) was thrown prior to reaching the session listener (i.e. the session listener was not called). I can try once more during today, if I can get a stacktrace from the session listener.
> FYI this is a pretty unusual situation. Usually, high-concurrency happens on different sessions and not the same one.
Our JMeter workload to hammer the server with concurrent requests on the same session is somewhat _extreme_, however, this was the only way we found that increases the likelyhood of the issue. In our real application we also do have multiple sessions and from my expectation a realistic workload from individual ones for a client-server application.
GitHub link: https://github.com/apache/shiro/discussions/2447#discussioncomment-15472446
----
This is an automatically sent email for issues@shiro.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@shiro.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@shiro.apache.org
For additional commands, e-mail: issues-help@shiro.apache.org
Re: [D] [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue) [shiro]
Posted by "aschwarte10 (via GitHub)" <gi...@apache.org>.
GitHub user aschwarte10 added a comment to the discussion: [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue)
@lprimak are there meanwhile any new insights? Do the additional logs provide helpful information?
GitHub link: https://github.com/apache/shiro/discussions/2447#discussioncomment-15538718
----
This is an automatically sent email for issues@shiro.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@shiro.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@shiro.apache.org
For additional commands, e-mail: issues-help@shiro.apache.org
Re: [D] [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue) [shiro]
Posted by "aschwarte10 (via GitHub)" <gi...@apache.org>.
GitHub user aschwarte10 edited a comment on the discussion: [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue)
Unfortunately no idea what the actual issue is.
We were receiving reports from our users that sessions expired, and over the last weeks we attempted to get an understanding. The only common denominator was ARM architecture. Before Christmas we managed to get it reproducible eventually with a heavy JMeter workload (100 Threads, hammering HTTP requests all using the same session id).
We also attempted to get an explanation from languange models. This may provide an underlying cause, but I am personally way to far away from the low levels processing to follow that in detail
Here is the main output - maybe it helps to get further understanding
> The Diagnosis: Thread Safety on ARM64
Apache Shiro's default SimpleSession implementation is not thread-safe. It uses standard Java fields (e.g., private Date lastAccessTime) without volatile keywords or synchronization.
On x86 processors (Intel/AMD), the hardware enforces a "Strong Memory Model." When one thread updates the session time, other threads (like the background validator) almost always see the update immediately, even without proper synchronization code.
On ARM64 processors (AWS Graviton r8g), the hardware uses a "Weak Memory Model." It is much more aggressive about caching variables in local CPU cores.
Thread A (User Request): Updates lastAccessTime to 3:23 PM. This value sits in Core 1's cache.
Thread B (Background Validator): Wakes up on Core 2. It reads the session's lastAccessTime. Because there is no volatile keyword, it might read a stale value from main memory (e.g., the session creation time from 31 minutes ago).
The Crash: Thread B calculates (Now - StaleTime) > 30 mins. It expires the session.
The Paradox: When Shiro constructs the error message, it likely triggers a memory refresh or reads the updated object reference, showing you the "Now" time, even though it just killed the session based on the "Old" time.
GitHub link: https://github.com/apache/shiro/discussions/2447#discussioncomment-15452290
----
This is an automatically sent email for issues@shiro.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@shiro.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@shiro.apache.org
For additional commands, e-mail: issues-help@shiro.apache.org
Re: [D] [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue) [shiro]
Posted by "aschwarte10 (via GitHub)" <gi...@apache.org>.
GitHub user aschwarte10 added a comment to the discussion: [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue)
We have tried out different CacheManagers, and also see the expiring session behavior with `MemoryConstrainedCacheManager`
A full stack trace (where the same `ExpiredSessionException` is caught in a slightly different place):
```
2026-01-09 14:25:28,635 ERROR [qtp343856911-40] org.apache.shiro.web.servlet.AbstractShiroFilter - session.touch() method invocation has failed. Unable to update the corresponding session's last access time based on the incoming request.
org.apache.shiro.session.ExpiredSessionException: Session with id [b3f97259-42bf-4e98-9472-7e4fa35054a4] has expired. Last access time: 1/9/26, 2:25 PM. Current time: 1/9/26, 2:25 PM. Session timeout is set to 1800 seconds (30 minutes)
at org.apache.shiro.session.mgt.SimpleSession.validate(SimpleSession.java:297)
at org.apache.shiro.session.mgt.AbstractValidatingSessionManager.doValidate(AbstractValidatingSessionManager.java:192)
at org.apache.shiro.session.mgt.AbstractValidatingSessionManager.validate(AbstractValidatingSessionManager.java:141)
at org.apache.shiro.session.mgt.AbstractValidatingSessionManager.doGetSession(AbstractValidatingSessionManager.java:118)
at org.apache.shiro.session.mgt.AbstractNativeSessionManager.lookupSession(AbstractNativeSessionManager.java:149)
at org.apache.shiro.session.mgt.AbstractNativeSessionManager.lookupRequiredSession(AbstractNativeSessionManager.java:153)
at org.apache.shiro.session.mgt.AbstractNativeSessionManager.touch(AbstractNativeSessionManager.java:232)
at org.apache.shiro.session.mgt.DelegatingSession.touch(DelegatingSession.java:120)
at org.apache.shiro.session.ProxiedSession.touch(ProxiedSession.java:100)
at org.apache.shiro.web.servlet.AbstractShiroFilter.updateSessionLastAccessTime(AbstractShiroFilter.java:330)
at org.apache.shiro.web.servlet.AbstractShiroFilter.lambda$doFilterInternal$0(AbstractShiroFilter.java:377)
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:91)
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:84)
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:389)
at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:376)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:156)
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1594)
at com.metaphacts.servlet.filter.ErrorLoggingFilter.doFilter(ErrorLoggingFilter.java:55)
at org.eclipse.jetty.ee10.servlet.FilterHolder.doFilter(FilterHolder.java:205)
at org.eclipse.jetty.ee10.servlet.ServletHandler$Chain.doFilter(ServletHandler.java:1594)
at org.eclipse.jetty.ee10.servlet.ServletHandler$MappedServlet.handle(ServletHandler.java:1555)
at org.eclipse.jetty.ee10.servlet.ServletChannel.dispatch(ServletChannel.java:822)
at org.eclipse.jetty.ee10.servlet.ServletChannel.handle(ServletChannel.java:438)
at org.eclipse.jetty.ee10.servlet.ServletHandler.handle(ServletHandler.java:470)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:575)
at org.eclipse.jetty.ee10.servlet.SessionHandler.handle(SessionHandler.java:717)
at org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:1102)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:181)
at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:611)
at org.eclipse.jetty.server.Server.handle(Server.java:182)
at org.eclipse.jetty.server.internal.HttpChannelState$HandlerInvoker.run(HttpChannelState.java:721)
at org.eclipse.jetty.server.internal.HttpConnection.onFillable(HttpConnection.java:416)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:322)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
at org.eclipse.jetty.io.SelectableChannelEndPoint$1.run(SelectableChannelEndPoint.java:53)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.runTask(AdaptiveExecutionStrategy.java:492)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.epcRunTask(AdaptiveExecutionStrategy.java:428)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.consumeTask(AdaptiveExecutionStrategy.java:401)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.tryProduce(AdaptiveExecutionStrategy.java:255)
at org.eclipse.jetty.util.thread.strategy.AdaptiveExecutionStrategy.run(AdaptiveExecutionStrategy.java:204)
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:311)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:981)
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.doRunJob(QueuedThreadPool.java:1211)
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1166)
at java.base/java.lang.Thread.run(Thread.java:1474)
```
Once such exception is visible in our logs, the user session is gone.
Note that this happens on "random" times - in my JMeter workload I have seen it after seconds, but also only after 6 minutes. So this indicates some kind of race condition.
Notes:
- I have never seen / reproduced this exception in an Intel / AMD64 environment (also not when running the same JMeter workload)
- When switching to the servlet container based session manager, I so far have never witnessed the exception
GitHub link: https://github.com/apache/shiro/discussions/2447#discussioncomment-15455435
----
This is an automatically sent email for issues@shiro.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@shiro.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@shiro.apache.org
For additional commands, e-mail: issues-help@shiro.apache.org
Re: [D] [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue) [shiro]
Posted by "lprimak (via GitHub)" <gi...@apache.org>.
GitHub user lprimak added a comment to the discussion: [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue)
Also, maybe you can get a (full) stack trace when session expiration happens? That would also be helpful
GitHub link: https://github.com/apache/shiro/discussions/2447#discussioncomment-15452515
----
This is an automatically sent email for issues@shiro.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@shiro.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@shiro.apache.org
For additional commands, e-mail: issues-help@shiro.apache.org
Re: [D] [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue) [shiro]
Posted by "aschwarte10 (via GitHub)" <gi...@apache.org>.
GitHub user aschwarte10 added a comment to the discussion: [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue)
Unfortunately no idea what the actual issue is.
We were receiving reports from our users that sessions expired, and over the last weeks we attempted to get an understanding. The only common denominator was ARM architecture. Before Christmas we managed to get it reproducible eventually with a heavy JMeter workload (100 Threads, hammering HTTP requests all using the same session id).
We also attempted to get an explanation from languange models. This may provide an underlying cause, but I am personally way to far away from the low levels processing to follow that
Here is the main output - maybe it helps to get further understanding
> The Diagnosis: Thread Safety on ARM64
Apache Shiro's default SimpleSession implementation is not thread-safe. It uses standard Java fields (e.g., private Date lastAccessTime) without volatile keywords or synchronization.
On x86 processors (Intel/AMD), the hardware enforces a "Strong Memory Model." When one thread updates the session time, other threads (like the background validator) almost always see the update immediately, even without proper synchronization code.
On ARM64 processors (AWS Graviton r8g), the hardware uses a "Weak Memory Model." It is much more aggressive about caching variables in local CPU cores.
Thread A (User Request): Updates lastAccessTime to 3:23 PM. This value sits in Core 1's cache.
Thread B (Background Validator): Wakes up on Core 2. It reads the session's lastAccessTime. Because there is no volatile keyword, it might read a stale value from main memory (e.g., the session creation time from 31 minutes ago).
The Crash: Thread B calculates (Now - StaleTime) > 30 mins. It expires the session.
The Paradox: When Shiro constructs the error message, it likely triggers a memory refresh or reads the updated object reference, showing you the "Now" time, even though it just killed the session based on the "Old" time.
GitHub link: https://github.com/apache/shiro/discussions/2447#discussioncomment-15452290
----
This is an automatically sent email for issues@shiro.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@shiro.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@shiro.apache.org
For additional commands, e-mail: issues-help@shiro.apache.org
Re: [D] [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue) [shiro]
Posted by "aschwarte10 (via GitHub)" <gi...@apache.org>.
GitHub user aschwarte10 edited a comment on the discussion: [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue)
Hi @lprimak ,
do you mean a `org.apache.shiro.session.SessionListener`?
If I remember correctly we have done this, however, the exception (at least in one control flow path) was thrown prior to reaching the session listener (i.e. the session listener was not called). I can try once more during today, if I can get a stacktrace from the session listener.
> FYI this is a pretty unusual situation. Usually, high-concurrency happens on different sessions and not the same one.
Our JMeter workload to hammer the server with concurrent requests on the same session is somewhat _extreme_, however, this was the only way we found that increases the likelyhood of the issue.
GitHub link: https://github.com/apache/shiro/discussions/2447#discussioncomment-15472446
----
This is an automatically sent email for issues@shiro.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@shiro.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@shiro.apache.org
For additional commands, e-mail: issues-help@shiro.apache.org
Re: [D] [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue) [shiro]
Posted by "aschwarte10 (via GitHub)" <gi...@apache.org>.
GitHub user aschwarte10 closed a discussion: [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue)
### Search before asking
- [x] I had searched in the [issues, **including closed issues**](https://github.com/apache/shiro/issues?q=is%3Aissue) and found no similar issues.
### Environment
Hi all,
in this ticket we want to share information about a potential concurrency issue in Shiro's DefaultWebSessionManager and open a discussion.
In our application we are using Shiro as the Security Framework together with Pac4j. We recently received issue reports about unexpected session expirations at random intervals.
Our technical team followed up and was able to reproduce the behavior with a specific HTTP workload against our application, basically firing a high number of requests and at some point it occurs.
We are only seeing the session expiration issue in ARM64 environments, i.e. we have never faced such errors on Intel or AM64 architectures so far.
Some technical notes:
- seems to happen only im ARM64 environments. We did a bit of research, and found that memory caching and the cache association to the CPU is different between Intel and ARM64.
- the issue happens under more heavy HTTP workloads
- if that is relevant, we are using Jetty 12.0.x (with Jakarta 10) and a Java 25 runtime environment
- for reproducing, we ran our application on an AWS EC2 instance with al2023-ami-2023.9.20251208.0-kernel-6.1-arm64 as base AMI
Our solution in our application is to switch to the ServletContainerSessionManager
As Shiro is a widely used framework, we are curious if the session expiration issue also occurred to others and also what the cause can be.
Please let us know if additional information is required.
### Shiro version
2.0.5
(happens also in 2.0.6)
### What was the actual outcome?
The error expresses with the following exception trace:
```
jakarta.servlet.ServletException: Filtered request failed. (edited)
Caused by: org.apache.shiro.session.ExpiredSessionException: Session with id [561d940e-1155-42fd-8b36-b2378511cd30] has expired. Last access time: 12/8/25, 3:07 PM. Current time: 12/8/25, 3:07 PM. Session timeout is set to 1800 seconds (30 minutes)
at org.apache.shiro.session.mgt.SimpleSession.validate(SimpleSession.java:297) ~[shiro-core-2.0.5]
```
Note that when we face the exception the "last access time" is always equal to the "current time".
### What was the expected outcome?
No unexpected ession expiration behavior.
### How to reproduce
We have a JMeter workload running a high number of requests (with concurrency) using the same session. At some point our workload starts to fail.
### Debug logs
_No response_
GitHub link: https://github.com/apache/shiro/discussions/2447
----
This is an automatically sent email for issues@shiro.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@shiro.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@shiro.apache.org
For additional commands, e-mail: issues-help@shiro.apache.org
Re: [D] [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue) [shiro]
Posted by "aschwarte10 (via GitHub)" <gi...@apache.org>.
GitHub user aschwarte10 added a comment to the discussion: [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue)
The only reproducting hints we have are described above: in the specific ARM environment with hammering the application server / shiro filters with requests.
GitHub link: https://github.com/apache/shiro/discussions/2447#discussioncomment-15844338
----
This is an automatically sent email for issues@shiro.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@shiro.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@shiro.apache.org
For additional commands, e-mail: issues-help@shiro.apache.org
Re: [D] [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue) [shiro]
Posted by "lprimak (via GitHub)" <gi...@apache.org>.
GitHub user lprimak added a comment to the discussion: [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue)
What cache manager are you using? Is it `MemoryConstrainedCacheManager` or something else?
Cache manager is the likely source of the race condition.
The LLM diagnosis is wrong. All session access goes through SessionDAO which is uses concurrent data structures.
GitHub link: https://github.com/apache/shiro/discussions/2447#discussioncomment-15452499
----
This is an automatically sent email for issues@shiro.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@shiro.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@shiro.apache.org
For additional commands, e-mail: issues-help@shiro.apache.org
Re: [D] [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue) [shiro]
Posted by "lprimak (via GitHub)" <gi...@apache.org>.
GitHub user lprimak added a comment to the discussion: [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue)
Thanks for the stack trace - it might be very helpful.
> Note that this happens on "random" times - in my JMeter workload I have seen it after seconds
This is weird. If your timeout is 1800 seconds (30 minutes) how can any session possibly expire after mere seconds?
It would be helpful to register a session invalidation listener and print out stack traces there to help debug this.
FYI this is a pretty unusual situation. Usually, high-concurrency happens on *different* sessions and not the same one.
This might not be a very well tested situation, and it's entirely possible that the race condition is in Shiro code.
It's also possible that the race condition is in the application code, or even an interaction or a combination of each.
GitHub link: https://github.com/apache/shiro/discussions/2447#discussioncomment-15458052
----
This is an automatically sent email for issues@shiro.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@shiro.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@shiro.apache.org
For additional commands, e-mail: issues-help@shiro.apache.org
Re: [D] [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue) [shiro]
Posted by "aschwarte10 (via GitHub)" <gi...@apache.org>.
GitHub user aschwarte10 edited a comment on the discussion: [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue)
Unfortunately no idea what the actual issue is.
We were receiving reports from our users that sessions expired, and over the last weeks we attempted to get an understanding. The only common denominator was ARM architecture. Before Christmas we managed to get it reproducible eventually with a heavy JMeter workload (100 Threads, hammering HTTP requests all using the same session id).
We also attempted to get an explanation from language models. This may provide an underlying cause, but I am personally way to far away from the low levels processing to follow that in detail
Here is the main output - maybe it helps to get further understanding
> The Diagnosis: Thread Safety on ARM64
Apache Shiro's default SimpleSession implementation is not thread-safe. It uses standard Java fields (e.g., private Date lastAccessTime) without volatile keywords or synchronization.
On x86 processors (Intel/AMD), the hardware enforces a "Strong Memory Model." When one thread updates the session time, other threads (like the background validator) almost always see the update immediately, even without proper synchronization code.
On ARM64 processors (AWS Graviton r8g), the hardware uses a "Weak Memory Model." It is much more aggressive about caching variables in local CPU cores.
Thread A (User Request): Updates lastAccessTime to 3:23 PM. This value sits in Core 1's cache.
Thread B (Background Validator): Wakes up on Core 2. It reads the session's lastAccessTime. Because there is no volatile keyword, it might read a stale value from main memory (e.g., the session creation time from 31 minutes ago).
The Crash: Thread B calculates (Now - StaleTime) > 30 mins. It expires the session.
The Paradox: When Shiro constructs the error message, it likely triggers a memory refresh or reads the updated object reference, showing you the "Now" time, even though it just killed the session based on the "Old" time.
GitHub link: https://github.com/apache/shiro/discussions/2447#discussioncomment-15452290
----
This is an automatically sent email for issues@shiro.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@shiro.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@shiro.apache.org
For additional commands, e-mail: issues-help@shiro.apache.org
Re: [D] [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue) [shiro]
Posted by "lprimak (via GitHub)" <gi...@apache.org>.
GitHub user lprimak added a comment to the discussion: [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue)
Unfortunately there is something weird going on (as evidenced by the logs) which will requires some major debugging effort and developing a reproducer.
I emailed you offline, did you by any chance notice those messages?
GitHub link: https://github.com/apache/shiro/discussions/2447#discussioncomment-15540326
----
This is an automatically sent email for issues@shiro.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@shiro.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@shiro.apache.org
For additional commands, e-mail: issues-help@shiro.apache.org
Re: [D] [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue) [shiro]
Posted by "lprimak (via GitHub)" <gi...@apache.org>.
GitHub user lprimak added a comment to the discussion: [Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue)
Hmmm... Can you please email me? My email is in the GH profile.
Thank you
GitHub link: https://github.com/apache/shiro/discussions/2447#discussioncomment-15551071
----
This is an automatically sent email for issues@shiro.apache.org.
To unsubscribe, please send an email to: issues-unsubscribe@shiro.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@shiro.apache.org
For additional commands, e-mail: issues-help@shiro.apache.org