[infinispan-dev] State transfer testing

[Mircea Markus]

On 19 Jul 2011, at 17:35, Bela Ban wrote:

> 
> 
> 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).
This is precisely the thing that worries me: with previous code B.x=2 didn't get lost. User's @Merge listener were called instead and the user could do some stuff to merge the state, but updates were not lost.
I agree that the previous approach placed a lot of burden on user's shoulder: merge the state "manually", but that was for a reason - not to loose consistency, which the current approach does. Hence my surprise to see it.
> 
> 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
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev