You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@zookeeper.apache.org by Be...@sungard.com on 2013/11/26 10:57:59 UTC
Leader election in C# client
Hi,
I was looking at the leader election algorithm in the .NET client at https://github.com/ewhauser/zookeeper/blob/trunk/src/dotnet/ZooKeeperNet.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 . ben.young@sungard.com . www.sungard.com
RE: Leader election in C# client
Posted by FPJ <fp...@yahoo.com>.
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: Ben.Young@sungard.com [mailto:Ben.Young@sungard.com]
> Sent: 26 November 2013 10:20
> To: user@zookeeper.apache.org
> 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:fpjunqueira@yahoo.com]
> Sent: 26 November 2013 10:10
> To: user@zookeeper.apache.org
> 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, <Be...@sungard.com> 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 . ben.young@sungard.com . www.sungard.com
> >
> >
> >
> >
> >
>
>
RE: Leader election in C# client
Posted by Be...@sungard.com.
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:fpjunqueira@yahoo.com]
Sent: 26 November 2013 10:10
To: user@zookeeper.apache.org
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, <Be...@sungard.com> wrote:
> Hi,
>
> I was looking at the leader election algorithm in the .NET client at https://github.com/ewhauser/zookeeper/blob/trunk/src/dotnet/ZooKeeperNet.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 . ben.young@sungard.com . www.sungard.com
>
>
>
>
>
Re: Leader election in C# client
Posted by Flavio Junqueira <fp...@yahoo.com>.
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, <Be...@sungard.com> wrote:
> Hi,
>
> I was looking at the leader election algorithm in the .NET client at https://github.com/ewhauser/zookeeper/blob/trunk/src/dotnet/ZooKeeperNet.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 . ben.young@sungard.com . www.sungard.com
>
>
>
>
>