shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cservenak, Tamas (JIRA)" <>
Subject [jira] [Commented] (SHIRO-443) SessionValidationScheduler created multiple times, enabling it is not thread safe
Date Thu, 23 May 2013 08:29:20 GMT


Cservenak, Tamas commented on SHIRO-443:

Added third UT that demonstrates a fix using DCL:
> SessionValidationScheduler created multiple times, enabling it is not thread safe
> ---------------------------------------------------------------------------------
>                 Key: SHIRO-443
>                 URL:
>             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):
> 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:

View raw message