Re: [infinispan-dev] State transfer testing
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/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).
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev