[infinispan-dev] State transfer testing

[Bela Ban]

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/org/infinispan/statetransfer/StateTransferFunctionalTest.java#L159
>>
>> 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