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