[ https://issues.jboss.org/browse/ISPN-2036?page=com.atlassian.jira.plugin.... ] Manik Surtani commented on ISPN-2036: ------------------------------------- I actually don't see the string "This adapter only works with CacheImpl, not with DelegatingCache" in the current codebase. Have you tried building off master or branch 5.1.x and trying again? The problem may well already be fixed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-2036?page=com.atlassian.jira.plugin.... ] Manik Surtani updated ISPN-2036: -------------------------------- Fix Version/s: 5.1.x Priority: Blocker (was: Major) Complexity: Low Forum Reference: https://community.jboss.org/thread/199126?tstart=0 (was: https://community.jboss.org/thread/199126?tstart=0) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-2036?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-2036: ---------------------------------------- Seems to me we have a mixed of classes really trying to do the same job: 1. o.i.t.CacheAdapter, created as a result of ISPN-841 2. o.i.DecoratedCache, created as a result of ISPN-1397 1) was created because within a tree cache operatin, multiple cache operations can be called, so that intermediate class was created to ship the flags no matter how many times the cache operation is called. 2) Really does the same thing, but for different reasons, to avoid the use of thread locals. Not 100% sure what the fix for this really is. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-2036?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-2036: ---------------------------------------- I've looked at this and can't see what the fix for this should be. Aside from the actual fix, there's a pretty entangled hierarchy of classes, added by several people, whose responsibility is not very clear, plus they're wasteful, i.e. AbstractDelegatingCache has a ref to Cache, and this class is extended by AbstractDelegatingAdvancedCache has a ref to AdvancedCache. Then, DecoratedCache extends AbstractDelegatingAdvancedCache adding yet another cache ref via CacheImpl. So, DecoratedCache has 3 references to the same cache instance :/ In paralel, there's another, very similar hierarchy: AbstractDelegatingCacheImpl extends AbstractDelegatingCache and adds a ref to CacheImp, so that's 2 cache refs. Then, AbstractDelegatingCacheImpl is extended twice: first by CacheAdapter (originally to support ISPN-841) which adds TreeContextContainer (which contains a thread local for flags), and secondly, DecoratedCacheAdapter (ISPN-1987), which seems to be the equivalent without a thread local. I'm not sure what this DelegatingCache that @Michael reports above, but my bet is that this is an AS class that comes from trying to use a cache instance coming from a call to Cache.withFlags() within AS. I've created a test that replicates this issue in https://github.com/galderz/infinispan/commit/e3b5cdbc0a991ea5b3f8a0c3d67d..., but the fix should clearly not be limited to DecoratedCache, but any potential delegates (i.e. delegates created within managed envs such as AS). @Manik, your suggested fix on IRC yesterday: {code}[17:18] <manik> galderz: maybe in CacheAdapter.withFlags() we should pass in the actual cache and not the CacheAdapter when constructing a DecoratedCacheAdapter [17:18] <manik> galderz: and also pass in the TreeCacheContext to the DecoratedCacheAdapter{code} does not seem to valid. DecoratedCacheAdapter constructor already receives the CacheImpl and TCC as parameters. @Manik, I've also got ISPN-1948 in the pipeline which is pretty important, so I'm gonna focus on that. Can I leave 2036 with you? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-2036?page=com.atlassian.jira.plugin.... ] Galder Zamarreño edited comment on ISPN-2036 at 5/11/12 5:14 AM: ----------------------------------------------------------------- I've looked at this and can't see what the fix for this should be. Aside from the actual fix, there's a pretty entangled hierarchy of classes, added by several people, whose responsibility is not very clear, plus they're wasteful, i.e. AbstractDelegatingCache has a ref to Cache, and this class is extended by AbstractDelegatingAdvancedCache has a ref to AdvancedCache. Then, DecoratedCache extends AbstractDelegatingAdvancedCache adding yet another cache ref via CacheImpl. So, DecoratedCache has 3 references to the same cache instance :/ In paralel, there's another, very similar hierarchy: AbstractDelegatingCacheImpl extends AbstractDelegatingCache and adds a ref to CacheImp, so that's 2 cache refs. Then, AbstractDelegatingCacheImpl is extended twice: first by CacheAdapter (originally to support ISPN-841) which adds TreeContextContainer (which contains a thread local for flags), and secondly, DecoratedCacheAdapter (ISPN-1987), which seems to be the equivalent without a thread local. I'm not sure what this DelegatingCache that @Michael reports above, but my bet is that this is an AS class that comes from trying to use a cache instance coming from a call to Cache.withFlags() within AS. I've created a test that replicates this issue in https://github.com/galderz/infinispan/commit/e3b5cdbc0a991ea5b3f8a0c3d67d..., but the fix should clearly not be limited to DecoratedCache, but any potential delegates (i.e. delegates created within managed envs such as AS). @Manik, your suggested fix on IRC yesterday: {code}[17:18] <manik> galderz: maybe in CacheAdapter.withFlags() we should pass in the actual cache and not the CacheAdapter when constructing a DecoratedCacheAdapter [17:18] <manik> galderz: and also pass in the TreeCacheContext to the DecoratedCacheAdapter{code} does not seem to valid. DecoratedCacheAdapter constructor already receives the CacheImpl and TCC as parameters. was (Author: galder.zamarreno): I've looked at this and can't see what the fix for this should be. Aside from the actual fix, there's a pretty entangled hierarchy of classes, added by several people, whose responsibility is not very clear, plus they're wasteful, i.e. AbstractDelegatingCache has a ref to Cache, and this class is extended by AbstractDelegatingAdvancedCache has a ref to AdvancedCache. Then, DecoratedCache extends AbstractDelegatingAdvancedCache adding yet another cache ref via CacheImpl. So, DecoratedCache has 3 references to the same cache instance :/ In paralel, there's another, very similar hierarchy: AbstractDelegatingCacheImpl extends AbstractDelegatingCache and adds a ref to CacheImp, so that's 2 cache refs. Then, AbstractDelegatingCacheImpl is extended twice: first by CacheAdapter (originally to support ISPN-841) which adds TreeContextContainer (which contains a thread local for flags), and secondly, DecoratedCacheAdapter (ISPN-1987), which seems to be the equivalent without a thread local. I'm not sure what this DelegatingCache that @Michael reports above, but my bet is that this is an AS class that comes from trying to use a cache instance coming from a call to Cache.withFlags() within AS. I've created a test that replicates this issue in https://github.com/galderz/infinispan/commit/e3b5cdbc0a991ea5b3f8a0c3d67d..., but the fix should clearly not be limited to DecoratedCache, but any potential delegates (i.e. delegates created within managed envs such as AS). @Manik, your suggested fix on IRC yesterday: {code}[17:18] <manik> galderz: maybe in CacheAdapter.withFlags() we should pass in the actual cache and not the CacheAdapter when constructing a DecoratedCacheAdapter [17:18] <manik> galderz: and also pass in the TreeCacheContext to the DecoratedCacheAdapter{code} does not seem to valid. DecoratedCacheAdapter constructor already receives the CacheImpl and TCC as parameters. @Manik, I've also got ISPN-1948 in the pipeline which is pretty important, so I'm gonna focus on that. Can I leave 2036 with you? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-2036?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2036: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-2036?page=com.atlassian.jira.plugin.... ] Manik Surtani reassigned ISPN-2036: ----------------------------------- Assignee: Galder Zamarreño (was: Manik Surtani) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-2036?page=com.atlassian.jira.plugin.... ] Michael Gronau commented on ISPN-2036: -------------------------------------- @Galder, i do not have a special test case for that, but i have tried to create a simple test class for you. Please make sure, to have a CacheContainer defined (described in the test class) in the standalone-full-ha.xml. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-2036?page=com.atlassian.jira.plugin.... ] Work on ISPN-2036 started by Galder Zamarreño. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-2036?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2036: ----------------------------------- Fix Version/s: 5.1.5.FINAL (was: 5.1.5.CR1) Git Pull Request: https://github.com/infinispan/infinispan/pull/1117, https://github.com/infinispan/infinispan/pull/1135 (was: https://github.com/infinispan/infinispan/pull/1117, https://github.com/infinispan/infinispan/pull/1135) Forum Reference: https://community.jboss.org/thread/199126?tstart=0 (was: https://community.jboss.org/thread/199126?tstart=0) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-2036?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-2036: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira