[ https://issues.apache.org/jira/browse/WSS-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alessio Soldano resolved WSS-587. --------------------------------- Resolution: Fixed > 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-unsubscr...@ws.apache.org For additional commands, e-mail: dev-h...@ws.apache.org