Cservenak, Tamas created SHIRO-443:
--------------------------------------
Summary: SessionValidationScheduler created multiple times,
enabling it is not thread safe
Key: SHIRO-443
URL: https://issues.apache.org/jira/browse/SHIRO-443
Project: Shiro
Issue Type: Bug
Components: Session Management
Affects Versions: 1.2.1
Reporter: Cservenak, Tamas
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!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
