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

On Mar 9, 2012 4:19 PM, "Bela Ban"<bban(a)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.

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.

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

> 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.

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.