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"<[email protected]> 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) _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
