[infinispan-dev] Non-blocking state transfer (ISPN-1424)

[Bela Ban]

Sorry for the delay, been busy ...

Comments inline.

On 3/9/12 7:20 PM, Dan Berindei wrote:
> On Mar 9, 2012 4:19 PM, "Bela Ban"<bban at redhat.com>  wrote:

>
>> My understanding (based on my changed in 4.2) is that state transfer
>> moves/deletes keys based on the diff between 2 subsequent views:
>> - Each node checks all of the affected keys
>> - If a key should be stored in additional nodes, the key is pushed there
>> - If a key shouldn't be stored locally anymore, it is removed
>>
>
>
> That's fine if we block all writes during state transfer, but once we start
> allowing writes during state transfer we need to log all changes and send
> them to the new owners at the end (the approach in 4.2 without your
> changes) or redirect all commands to the new owners.


OK


> In addition to that, we have to either block all commands on the new owners
> until they receive the entire state or to forward get commands to the old
> owners as well. The two options apply for lock commands as well.


Why do we have to lock at all if we use queueing of requests during a 
state transfer ?


> I'm not trying to make merges more complicated on purpose :)


I didn't imply that; but I thought the London design was pretty simple, 
and I'm trying to figure out why we have such a big (maybe perceived) 
diff between London and what's in the document.


>> Also, why do we need to transfer ownership information ? Can't ownership
>> be calculated purely on local information ?
>>
>
>
> The current ownership information can be calculated based solely on the
> members list. But the ownership in the previous cache view(s) can not be
> computed by joiners based only on their information, so it has to be
> broadcasted by the coordinator.


OK



> One particularly nasty problem with the existing, blocking, state transfer
> is that before iterating the data container we need to wait for all the
> pending commands to finish.


Can't we queue the state transfer requests *and* the regular requests ? 
When ST is done, we apply the ST requests first, then the queued regular 
requests.



-- 
Bela Ban, JGroups lead (http://www.jgroups.org)