Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.2.1
-
None
Description
DefaultSessionManager superclass AbstractValidatingSessionManager enables SessionValidatorScheduler on-demand, not on creation. Validation is enabled by any of the two SessionManager methods: start(context) or getSession(key). But none of the methods has proper synchronisation around critical methods like org.apache.shiro.session.mgt.AbstractValidatingSessionManager.enableSessionValidation() or org.apache.shiro.session.mgt.AbstractValidatingSessionManager.enableSessionValidationIfNecessary().
Problem is that in case of parallel incoming requests (like two concurrent HTTP request in web application), two instances (or more than one) instances of SessionValidationScheduler will be created (which are by default ExecutorServiceSessionValidationScheduler). This results in multiple threads competing around for session validation. While this does NOT cause problems in Shiro operations (multiple threads validating sessions is synchronised just fine), it looks very awkward in thread dumps and logs, and is usually source of confusion or "false alarms".
Repository that contains sample code (with possible workaround for Shiro integrators):
https://github.com/cstamas/shiro-session-validation-thread
Note: I did not fiddle to properly assert, but when you run from CLI and inspect the thread dump, you can see how SessionManagerTest ends up with 3 threads (as many concurrent session requests are made), on my system named as "Thread-0", "Thread-1" and "Thread-2". While the SessionManagerWorkaroundTest creates only "Thread-0". If running from IDE, don't forget to run the tests in separate JVMs, otherwise the daemon threads will remain from one test during execution of another!
Attachments
Issue Links
- is related to
-
-
- Resolved
-