ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alessio Soldano (JIRA)" <>
Subject [jira] [Created] (WSS-587) Concurrency issue in EHCacheManagerHolder
Date Mon, 19 Sep 2016 08:14:20 GMT
Alessio Soldano created WSS-587:

             Summary: Concurrency issue in EHCacheManagerHolder
                 Key: WSS-587
             Project: WSS4J
          Issue Type: Bug
          Components: WSS4J Core
    Affects Versions: 2.1.7
            Reporter: Alessio Soldano
            Assignee: Alessio Soldano
             Fix For: 2.2.0, 2.1.8

I'm currently seeing an intermittent issue in the JBossWS-CXF testsuite
(stacktrace at ),
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.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message