Uploaded image for project: 'WSS4J'
  1. WSS4J
  2. WSS-587

Concurrency issue in EHCacheManagerHolder

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.9, 2.1.7
    • Fix Version/s: 2.2.0, 2.0.10, 2.1.8
    • Component/s: WSS4J Core
    • Labels:
      None

      Description

      I'm currently seeing an intermittent issue in the JBossWS-CXF testsuite
      (stacktrace at https://paste.fedoraproject.org/428145/14738847/raw/ ),
      with the CXF EHCacheTokenStore creation failing due to the CacheManager having
      been shutdown. The testsuite includes multiple tests, almost all of them
      create jaxws clients and in most of them the current thread bus is used
      (few of them do create a new bus, set it as default thread bus, run and
      eventually shutdown the bus). What I suspect is some kind of concurrency
      issue in the CacheManager lifecycle management.

      I've looked a bit at the code and noticed that there's basically a 1-1
      relationship between Bus instances and CacheManager instances. Given I have
      some tests that do not explicitly shutdown the bus (or the client) after
      execution, it can happen that a client is closed because the JDK eventually
      finalize ClientProxy, which in the end causes the CacheCleanupListener to
      close the token store and hence to release/shutdown the cache manager (see
      the invocation flow at https://paste.fedoraproject.or
      g/428150/47388530/raw/ ). Unfortunately that exact cache manager could
      possibly be in use to serve another client running in the same bus. AFAICS,
      there's an attempt to avoid problems like this in WSS4J's
      EHCacheManagerHolder (which deals with CXF requests of creating/releasing
      cache managers), as it has a ConcurrentHashMap<String, AtomicInteger>
      attribute to keep track of how many consumers of a given cache manager are
      there and avoid shutting down a manager if it's still in use. Looking at
      its getCacheManager and releaseCacheManager methods I can see a possible
      concurrency flaw which could be the root of my failure. The
      releaseCacheManager method could be called with cacheManager X as parameter
      while a different thread is running getCacheManager and is just before line
      106 (that is just before the AtomicInteger is got from the map) with local
      cacheManager variable already resolved to X. That should later deal to an
      attempt to use an already shutdown cache manager.

        Attachments

          Activity

            People

            • Assignee:
              asoldano Alessio Soldano
              Reporter:
              asoldano Alessio Soldano
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: