[jira] [Commented] (WSS-587) Concurrency issue in EHCacheManagerHolder
[ https://issues.apache.org/jira/browse/WSS-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15502880#comment-15502880 ] Alessio Soldano commented on WSS-587: - Applied fix: https://github.com/apache/wss4j/commit/311cad0cc87b6a82c796b213b6ea7b49cde641ed > 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> 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
[jira] [Work stopped] (WSS-587) Concurrency issue in EHCacheManagerHolder
[ https://issues.apache.org/jira/browse/WSS-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on WSS-587 stopped 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> 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
[jira] [Resolved] (WSS-587) Concurrency issue in EHCacheManagerHolder
[ 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> 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
[jira] [Work started] (WSS-587) Concurrency issue in EHCacheManagerHolder
[ 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> 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
[jira] [Updated] (WSS-587) Concurrency issue in EHCacheManagerHolder
[ https://issues.apache.org/jira/browse/WSS-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessio Soldano updated WSS-587: Fix Version/s: 2.0.10 > 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> 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
[jira] [Commented] (WSS-587) Concurrency issue in EHCacheManagerHolder
[ https://issues.apache.org/jira/browse/WSS-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15502862#comment-15502862 ] Alessio Soldano commented on WSS-587: - OK :-) > 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> 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
[jira] [Updated] (WSS-587) Concurrency issue in EHCacheManagerHolder
[ https://issues.apache.org/jira/browse/WSS-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alessio Soldano updated WSS-587: Affects Version/s: 2.0.9 > 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> 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
[jira] [Commented] (WSS-587) Concurrency issue in EHCacheManagerHolder
[ https://issues.apache.org/jira/browse/WSS-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15502808#comment-15502808 ] Colm O hEigeartaigh commented on WSS-587: - Ok thanks. Go ahead and backmerge to 2.0.x then I guess. > 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.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 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> 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
[jira] [Commented] (WSS-587) Concurrency issue in EHCacheManagerHolder
[ https://issues.apache.org/jira/browse/WSS-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15502804#comment-15502804 ] Alessio Soldano commented on WSS-587: - [~coheigea] oh, well, I don't know for sure. The affected methods in 2.0 are the same as in 2.1 and trunk afaics, so likely yes. Perhaps something was different in the past in either CXF or JBossWS, in a way that prevented this issue from being spotted... > 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.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 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> 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
[jira] [Commented] (WSS-587) Concurrency issue in EHCacheManagerHolder
[ https://issues.apache.org/jira/browse/WSS-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15502740#comment-15502740 ] Colm O hEigeartaigh commented on WSS-587: - Is the bug present in 2.0 as well? > 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.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 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> 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
[jira] [Created] (WSS-587) Concurrency issue in EHCacheManagerHolder
Alessio Soldano created WSS-587: --- Summary: 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.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 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 ConcurrentHashMapattribute 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