You should also be careful how you handle connection loss events. The
leader should suspend itself and re-run the election process when the
connection is reestablished.
On Sat, Sep 4, 2010 at 8:37 AM, Mahadev Konar <maha...@yahoo-inc.com> wrote:
> Hi Eric,
> As Ted and you yourself mentioned its mostly to avoid herd affect. A herd
> affect would usually mean 1000¹s of client notified of some change and would
> try creating the same node on notification. With just 10¹s of clients you
> don¹t need to worry abt this herd effect at all.
>
> Thanks
> mahadev
>
>
> On 9/2/10 3:40 PM, "Ted Dunning" <ted.dunn...@gmail.com> wrote:
>
>> You are correct that this simpler recipe will work for smaller populations
>> and correct that the complications are to avoid the herd effect.
>>
>>
>>
>> On Thu, Sep 2, 2010 at 12:55 PM, Eric van Orsouw
>> <eric.van.ors...@gmail.com>wrote:
>>
>>> Hi there,
>>>
>>>
>>>
>>> I would like to use zookeeper to implement an election scheme.
>>>
>>> There is a recipe on the homepage, but it is relatively complex.
>>>
>>> I was wondering what was wrong with the following pseudo code;
>>>
>>>
>>>
>>> forever {
>>>
>>> zookeeper.create -e /election <my_ip_address>
>>>
>>> if creation succeeded then {
>>>
>>> // do the leader thing
>>>
>>> } else {
>>>
>>> // wait for change in /election using watcher mechanism
>>>
>>> }
>>>
>>> }
>>>
>>>
>>>
>>> My assumption is that the recipe is more elaborate to the eliminate the
>>> flood of requests if the leader falls away.
>>>
>>> But if there are only a handful of leader-candidates ,than that should not
>>> be a problem.
>>>
>>>
>>>
>>> Is this correct, or am I missing out on something.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Eric
>>>
>>>
>>>
>>>
>>
>
>
--
Andrei Savu -- http://www.andreisavu.ro/
