[
https://issues.apache.org/jira/browse/SHIRO-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13664987#comment-13664987
]
Cservenak, Tamas commented on SHIRO-443:
----------------------------------------
Added third UT that demonstrates a fix using DCL:
https://github.com/cstamas/shiro-session-validation-thread/blob/master/src/test/java/org/cstamas/shiro/SessionManagerFixTest.java
> 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
