Re: [infinispan-dev] State transfer testing
On 7/19/11 5:36 PM, Mircea Markus wrote:
On 19 Jul 2011, at 09:38, Galder Zamarreño wrote:
> Hi all,
>
> I've noticed a problem with the way we test state transfer in our testsuite. For
example, take
https://github.com/infinispan/infinispan/blob/master/core/src/test/java/o...
>
> This test checks that when a new node is started, state transfer happens. But, it
could happen that a merge happens instead of a join, so if a merge happens no state
transfer occurs.
that was my understanding as well. And I think it still stands for REPL.
I've just had a chat with Dan and also looked at the code[1]: for distributed caches,
if a merge view happens, the rehashing is triggered in exactly the same way as when a join
happens.
That worries me, as consistency is affected if a key is modified in one (or both) of the
cluster's partition after the split brain. Or am I missing something?
I wrote that to reduce code; the code to join is essentially the same as
the code to merge. For me, this is the same.
Now, there *is* a problem. Consider we have partitions {A} and {B}, and
some clients are able to access A and others B. Now value x (which is 1)
is set to 2 in B.
When there's a merge into {A,B} and A turns out to be the (existing and
new) primary owner of x, then it'll update B.x=1 (*if* B is the backup
owner of x, or else B will remove x).
If B turns out to be the primary owner, then it will update A.x=2 (*if*
A is the backup owner for x).
Since we have never handled merge situations, neither in JBossCache, not
in Infinispan, I think we're fine for me. Of course, this needs to be
addressed, but that's a separate discussion (albeit a very important one
!)...
We could use seqnos and let the user decide, on a merge, which value is
the correct one, unless we can merge them without conflicts.
--
Bela Ban
Lead JGroups (http://www.jgroups.org)
JBoss / Red Hat