Uploaded image for project: 'Shiro'
  1. Shiro
  2. SHIRO-443

SessionValidationScheduler created multiple times, enabling it is not thread safe

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.2.1
    • Fix Version/s: 1.2.5
    • Component/s: Session Management
    • Labels:
      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

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                cstamas Tamás Cservenák
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: