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 [email protected].
To unsubscribe, please send an email to: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
