<p>
On Mar 9, 2012 4:19 PM, "Bela Ban" <<a href="mailto:bban@redhat.com" target="_blank">bban@redhat.com</a>> wrote:<br>
><br>
> Wow !<br>
><br>
> Does this need to be so complex ? I've spent a hour trying to understand<br>
> it, and am still overwhelmed... :-)<br>
></p><p><br></p><p>Sorry about that Bela, it is quite complex indeed.<br></p><p><br>
</p><p>> My understanding (based on my changed in 4.2) is that state transfer<br>
> moves/deletes keys based on the diff between 2 subsequent views:<br>
> - Each node checks all of the affected keys<br>
> - If a key should be stored in additional nodes, the key is pushed there<br>
> - If a key shouldn't be stored locally anymore, it is removed<br>
></p><p><br></p><p>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.</p>
<p>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.<br>
</p><p><br>
</p><p>> IMO, there's no need to handle a merge differently from a regular view,<br>
> and we might end up with inconsistent state, but that's unavoidable<br>
> until we have eventual consistency. Fine...<br>
></p><p><br></p><p>I'm not trying to make merges more complicated on purpose :)<br></p><p>I think we need to try our best to prevent data loss, even if we there is a chance of inconsistency. We still see clusters in the test suite form via merges from time to time, so we can't just say after a merge all bets are off.<br>
</p><p>The problem is that I chose to forward get commands to the old owners AND to remove the cache view rollback (which was blocking in our Lisbon design). This means that we must keep a chain of cache views for which we haven't finished state transfer, and with merges that chain turns into a tree + it has to be broadcasted by the coordinator to all the nodes.<br>
</p><p></p><p><br>
</p><p>> Also, why do we need to transfer ownership information ? Can't ownership<br>
> be calculated purely on local information ?<br>
></p><p><br></p><p>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.<br>
</p><p><br>
> I'm afraid that the complexity will increase the state space (hard to<br>
> test all possible state transitions), lead to unnecessary messages being<br>
> sent and most importantly, might lead to blocks.<br>
></p><p><br></p><p>I agree the increased complexity is a concern, but I'm not willing to give up on non-blocking state transfer just yet...</p><p>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. So if we have high contention and a 60 seconds lock acquisition timeout, state transfer is almost guaranteed to take > 60 seconds.<br>
</p><p><br></p><p>
> The section on locking outright scares me :-) Perhaps reducing the level<br>
> of details here - as Galder suggested - might help to understand the<br>
> basic design.<br>
></p><p><br></p><p>I got burned pretty hard with my asymmetric clusters design, because the implementation turned out a lot more complex than the design, so I tried to investigate all the interactions between the different choices we're making this time.<br>
</p><p><br></p><p>
> Sorry for being a bit negative, but I think state transfer is one of the<br>
> most critical and important pieces of code in DIST mode, and this needs<br>
> to work against large (say a couple of hundreds) clusters and nodes<br>
> joining, leaving or crashing all the times...<br>
></p><p><br></p><p>I'd argue that the blocking state transfer we have doesn't satisfy this requirement...<br></p><p><br></p><p>
> I'm going to re-read the design again, maybe what I said above is just<br>
> BS ... :-)<br>
></p><p><br></p><p>Please do re-read it, I'll try to simplify it a bit by Monday based on your feedback.<br></p><p><br></p><p>
><br>
> On 3/8/12 11:55 AM, Dan Berindei wrote:<br>
> > Hi guys<br>
> ><br>
> > It's been a long time coming, but I finally published the non-blocking<br>
> > state transfer draft on the wiki:<br>
> > <a href="https://community.jboss.org/wiki/Non-blockingStateTransfer" target="_blank">https://community.jboss.org/wiki/Non-blockingStateTransfer</a><br>
> ><br>
> > Unlike my previous state transfer design document, I think I've<br>
> > fleshed out most of the implications. Still, there are some things I<br>
> > don't have a clear solution for yet. As you would expect it's mostly<br>
> > around merging and delayed state transfer.<br>
> ><br>
> > I'm looking forward to hearing your comments/advice!<br>
> ><br>
> > Cheers<br>
> > Dan<br>
> ><br>
> > PS: Let's discuss this over the mailing list only.<br>
> ><br>
> --<br>
> Bela Ban, JGroups lead (<a href="http://www.jgroups.org" target="_blank">http://www.jgroups.org</a>)<br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</p>