[Bug] Unexpected session expiration behavior on ARM64 architecture (Concurrency Issue)

[aschwarte10]

Search before asking

• I had searched in the issues, including closed issues 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

[lprimak]

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?

[aschwarte10]

@lprimak are there meanwhile any new insights? Do the additional logs provide helpful information?

[lprimak]

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?

[aschwarte10]

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.

[lprimak]

Hmmm... Can you please email me? My email is in the GH profile.
Thank you

[lprimak]

Just wanted to know if you received my email, thanks!