Again, I don't know what the C# client is doing, since we don't directly support that client here. However, it seems right to me that a client only watches the previous znode. The idea again is that an ephemeral going away generates only one notification instead of O(n), where n is the total number of bidders.
Please note the following. The algorithm that seems to be implemented there has the advantage that it avoids the herd effect, but as a consequence of that, not all clients are notified of a leader change. -Flavio > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: 26 November 2013 10:20 > To: [email protected] > Subject: RE: Leader election in C# client > > Thanks Flavio, makes sense. I'm trying to convince myself that the effect is > the same even though it doesn't strictly order in the actual sequential order, > as long as all the clients see the same consistent order! > > I also notice the code only watches for the previous going away and then > assumes it's the leader, which I think is wrong, it should re-run the check on > previous nodes again I think > > Thanks, > Ben > > -----Original Message----- > From: Flavio Junqueira [mailto:[email protected]] > Sent: 26 November 2013 10:10 > To: [email protected] > Subject: Re: Leader election in C# client > > Hi Ben, > > I'm not familiar with the C# implementation, but I suspect that: > > - The session id is indeed to be able to identify the znode in the case the > client sees a connection loss event and reexecutes the create; > - The sequence number creates an order among the bidders so that when a > master crashes (ephemeral znode goes away), not all clients are notified. > This solves the herd effect problem: many nodes being notified upon a single > znode going away. > > -Flavio > > > On Nov 26, 2013, at 9:57 AM, <[email protected]> wrote: > > > Hi, > > > > I was looking at the leader election algorithm in the .NET client at > https://github.com/ewhauser/zookeeper/blob/trunk/src/dotnet/ZooKeepe > rNet.Recipes/LeaderElection.cs > > > > There is a point I don't understand and I was wondering if someone could > clarify for me. The recipe creates ephemeral nodes of the form "election- > <sessionid>-<sequentialid>", I think to be able to see if it has already created > the node (perhaps due to a retry?). However, doesn't having the session id > in the node name then throw out the sorting of the nodes in the next step, > to find the previous node to watch? I'd have thought it would then be sorting > by session id and not sequential id? Perhaps that doesn't matter as long as > only one node gets picked? > > > > Thanks, > > Ben > > > > Ben Young . Senior Software Engineer . Adaptiv . Position, Risk & > Operations . SunGard . Enterprise House, Histon, Cambridge, CB24 9ZR . Tel > +44 (0) 1223 266042 . [email protected] . www.sungard.com > > > > > > > > > > > >
