[jira] [Commented] (SHIRO-443) SessionValidationScheduler created multiple times, enabling it is not thread safe

["Cservenak, Tamas (JIRA)" <ji...@apache.org>]

    [ 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