Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # user >> zookeeper leadership election example application


Copy link to this message
-
Re: zookeeper leadership election example application
I have embedded similar code into a number of programs, but I haven't
published them.

You could take a look at hbase.  I think it uses the single file technique.

On Sat, Nov 26, 2011 at 2:33 AM, Jérémie BORDIER
<[EMAIL PROTECTED]>wrote:

> Hello Ted,
>
> Can you point to a good implementation of that single file leadership
> election method you're describing ?
>
> Thanks,
> Jérémie
>
> On Sat, Nov 26, 2011 at 8:37 AM, Ted Dunning <[EMAIL PROTECTED]>
> wrote:
> > I think that the code also needs:
> >
> > * comments.  You need to put some java docs in that say what the
> different
> > classes and methods are intended to do.  External documentation is nice,
> > but hardly sufficient.
> >
> > * global handling of disconnection and pausing of masters during a
> > disconnect.
> >
> > * a description of how you think you are handling error conditions
> >
> > * tests that demonstrate that you handle error conditions
> >
> > I would also take issue with Jordan's suggestion for retry logic.  With
> > ephemeral sequential node, retries are very dangerous in certain corner
> > failure modes.  This is the primary reason that I prefer the single file
> > leader election method.  With a reasonable number of masters (the most
> > common case) this is completely sufficient since the herd effect isn't a
> > problem for such a small herd.
> >
> > On Fri, Nov 25, 2011 at 10:17 PM, Jordan Zimmerman
> > <[EMAIL PROTECTED]>wrote:
> >
> >> A few comments:
> >>
> >> * NodeMonitor.createRootIfNotExists() should catch NodeExists. In the
> case
> >> of multiple clients, this is a possibility.
> >>
> >> * I'd add a start method and create the ZooKeeper instance there. This
> >> gives users a chance to set a listener so as to receive all messages.
> >>
> >> * All ZooKeeper operations should be in some kind of retry loop. The
> >> client can lose connection to a given server but successfully reconnect
> to
> >> another one in the cluster.
> >>
> >> * When creating the Znode, it can succeed on the server but fail to
> return
> >> the result to the client. On a Disconnect/Session exception, you should
> >> retry and then call getChildren and search for your node.
> >>
> >> -JZ
> >>
> >> On 11/25/11 2:45 AM, "Olivier Van Acker" <[EMAIL PROTECTED]> wrote:
> >>
> >> >I've written a example app on how to do implement leadership election
> in
> >> >with zookeeper
> >> >Is there anyone on the list who'd like to review my app and if it needs
> >> >improvement or not?
> >> >
> >> >the app is on github:
> >> >https://github.com/cyberroadie/zookeeper-leader
> >> >
> >> >and explained how it works on my blog:
> >> >
> >>
> http://cyberroadie.wordpress.com/2011/11/24/implementing-leader-election-w
> >> >ith-zookeeper/
> >> >
> >> >Olivier
> >>
> >>
> >
>
>
>
> --
> Jérémie 'ahFeel' BORDIER
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB