Bela, https://jira.jboss.org/jira/browse/ISPN-240 explains why the removals are not working as expected in the stress test you wrote. Cheers,

Galder Zamarreno wrote: > I've replicated this in > https://svn.jboss.org/repos/infinispan/trunk/core/src/test/java/org/infin... > > When we call getFirstNonOwner("k1").put("k1", "value"); apart from > replicating k1 to the owners of k1, it also resides in the non owner. > So, when we call getOwners("k1")[0].remove("k1");, it will only > remove > it from those nodes where k1 is owner. The end result is that a > non-owner ends up with k1. > > The fix for this does not seem trivial: You either, avoid non-owners > storing data in the cache if DIST and !L1, or when !L1, do a cluster > wide removal. For me, the fix is clear: a non-owner must never store a key ! Or else we defy the purpose of DIST and have too many copies of data in a grid !

On 29 Oct 2009, at 11:50, Galder Zamarreno wrote: > I've replicated this in > https://svn.jboss.org/repos/infinispan/trunk/core/src/test/java/org/infin... > > When we call getFirstNonOwner("k1").put("k1", "value"); apart from > replicating k1 to the owners of k1, it also resides in the non owner. > So, when we call getOwners("k1")[0].remove("k1");, it will only remove > it from those nodes where k1 is owner. The end result is that a > non-owner ends up with k1. > > The fix for this does not seem trivial: You either, avoid non-owners > storing data in the cache if DIST and !L1, or when !L1, do a cluster > wide removal. > > The first option looks to be more correct one. If I don't have an L1 > and > I'm not the owner of k1, why should I keep it at all? Maybe this could > be implemented via a Flag, i.e. Flag.SKIP_CACHE (you'd probably need > to > use Flag.SKIP_CACHE_STORE too to avoid putting in the cache store). > > With the second option, you'd have to start figuring out which other > ops > would need to be executed cluster wide regardless of ownership when L1 > is disabled. More prone to errors IMO. And the actual fix is actually pretty trivial. It is in the DistLockingInterceptor, where we commit changes to an entry in the context. At this point we just need to decide whether we keep the changes (write to the data container) or discard them (they were only temporary for replication). I have just checked in a fix for this. > > Thoughts? > > On 10/29/2009 11:41 AM, Galder Zamarreno wrote: >> Bela, >> >> https://jira.jboss.org/jira/browse/ISPN-240 explains why the removals >> are not working as expected in the stress test you wrote. >> >> Cheers, > > -- > Galder Zamarreño > Sr. Software Engineer > Infinispan, JBoss Cache > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev