[jira] [Work started] (WSS-587) Concurrency issue in EHCacheManagerHolder

["Alessio Soldano (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WSS-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on WSS-587 started by Alessio Soldano.
-------------------------------------------
> Concurrency issue in EHCacheManagerHolder
> -----------------------------------------
>
>                 Key: WSS-587
>                 URL: https://issues.apache.org/jira/browse/WSS-587
>             Project: WSS4J
>          Issue Type: Bug
>          Components: WSS4J Core
>    Affects Versions: 2.0.9, 2.1.7
>            Reporter: Alessio Soldano
>            Assignee: Alessio Soldano
>             Fix For: 2.2.0, 2.0.10, 2.1.8
>
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org