You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by Patrick Hunt <ph...@apache.org> on 2008/07/17 19:17:46 UTC
Recipe contrib -- was Re: [PATCH] a simple Leader Election or exclusive
Write Lock protocol/policy
James, thanks for the contribution! Tests and everything. :-)
Jacob sent some mail to the list recently (attached) that details a
protocol that he's used successfully (and picked up by some zk users). I
have a todo item to document this protocol on the recipes wiki page,
haven't gotten to it yet. Not sure how/if this matches what you've done
but we should sync up (also see below).
https://issues.apache.org/jira/browse/ZOOKEEPER-79
There has been some discussion on client side helper code in the past
however this is the first contribution. We need to make some decisions
and outline what/how we will accept.
1) I think we should have a
"contrib/recipes/{java/{main,test}/org/apache/zookeeper/... ,c/,...}"
hierarchy for contributions that implement recipes, including any helper
code
2) We should first document recipes on the wiki, then implement them in
the code
http://wiki.apache.org/hadoop/ZooKeeper/ZooKeeperRecipes
The code should fully document the api/implementation, and refer to wiki
page for protocol specifics.
3) What should we do relative to ZK releases. Are recipes included in a
release? Will bugs in recipes hold up a release?
My initial thought is that contrib is available through svn, but not
included in the release. If users want to access/use this code they will
be required to checkout/build themselves. (at least initially)
4) We will not require "parody" btw the various client languages.
Currently we support Java/C clients, we will be adding various scripting
languages soon. Contributions will be submitted for various clients
(James' submission is for java), that will be placed into contrib, if
someone else contributes C bindings (etc...) we will add those to
contrib/recipes as well.
5) Implementations should strive to implement similar recipe protocols
(see 2 above, a good reason to document before implement). There may be
multiple, different, protocols each with their own implementation, but
for a particular protocol the implementations should be the same.
We may want to stress 5 even more - if multiple clients implementations
(c/java/...) are participating in a single instance of leader election
it will be CRITICAL for them to be inter-operable.
Comments, questions, suggestion?
Patrick
James Strachan wrote:
> So having recently discovered ZooKeeper, I'm really liking it - good job folks!
>
> I've seen discussions of building high level features from the core ZK
> library and had not seen any available on the interweb so figured I'd
> have a try creating a simple one. Feel free to ignore it if a ZK ninja
> can think of a neater way of doing it - I've basically followed the
> protocol defined in the recent ZK presentation...
> http://developer.yahoo.com/blogs/hadoop/2008/03/intro-to-zookeeper-video.html
>
> I've submitted the code as a patch here...
> https://issues.apache.org/jira/browse/ZOOKEEPER-78
>
> I figured the Java Client might as well come with some helper code to
> make doing things like exclusive locks or leader elections easier; we
> could always spin them out into a separate library if and when
> required etc. Right now its one fairly simple class :)
>
> Currently its a simple class where you can register a Runnable to be
> invoked when you have the lock; or you can just keep asking if you
> have the lock now and again as you see fit etc.
>
> WriteLock locker = new WriteLock(zookeeper, "/foo/bar");
> locker.setWhenOwner(new Runnable() {...}); // fire this code when owner...
>
> // lets try own it
> locker.acquire();
>
> // I may or may not have the lock now
> if (locker.isOwner()) {....}
>
> // time passes
> locker.close();
>
>
> Thoughts?
>
Re: Recipe contrib -- was Re: [PATCH] a simple Leader Election or
exclusive Write Lock protocol/policy
Posted by Patrick Hunt <ph...@gmail.com>.
Doug Cutting wrote:
> Patrick Hunt wrote:
>> my original intent was to have it as zookeeper/trunk/src/contrib/...
>> where this directory will have not only recipes but also other
>> contributions.
>
> +1 That's what I meant too. And since you've said you want to package
> these all as a single jar, then there should just be a single tree per
> language, right?
Yes, that's right.
>
> zookeeper/trunk/src/contrib/recipes/src/java/org/apache/zookeeper/recipes/locking/
> zookeeper/trunk/src/contrib/recipes/src/c++/locking/
>
Right.
> I don't see the strong connection between releases and new features.
....
> Am I missing something?
I think that the issue is implied connotation of "contrib".
We were thinking of contrib as "interesting stuff that users might want
to re-use/share but not core to zookeeper, we'll carry it around so that
users know where to find it, if it gets broken and no one fixes it it
won't hold up the release"
If I understand correctly you are saying there is no middle ground.
Patrick
Re: Recipe contrib -- was Re: [PATCH] a simple Leader Election or exclusive Write Lock protocol/policy
Posted by James Strachan <ja...@gmail.com>.
As a newbie around hadoop/zookeeper (but long time apache hacker on
various things), I think the high level protocol/recipe stuff should
definitely be a separate, released module; so folks who wanna use it
can share a versioned binary and so forth. It would be awesome to have
a few good protocols/recipes for things like leader election, write
locks, read/write locks - maybe load balancing (e.g. sparse hash maps
and whatnot) - plus maybe more distributed java-util-concurrent stuff
like barriers etc. Even if folks don't reuse the recipes at least they
can act as good educational material for using the core ZK client API
etc.
I don't see a huge need yet to split these Java recipe's into multiple
individual releases/jars yet - as we're talking a pretty small
codebase, so a single zookeeper-recipe.jar would suffice for now. e.g.
for leader election & exclusive write locks we're talking two classes
probably; maybe with a few interface hooks or something. I'd be
tempted to stick with all the recipe's in a single jar for now - then
if we find some complex recipe's coming along that are more
specialised and require loads of code, we could spin those out later
but many of the core recipe's are gonna be pretty small in terms of
code and I can also see a small chunk of code being reusable in a few
recipe's etc. (e.g. exclusive write locks are kinda the same thing as
leader election).
The bigger decision is more do we release the core Java API/impl to ZK
with the recipe's or as a separate release process. Certainly the core
of ZK is pretty stable; the recipe's are gonna be in a state of flux &
rapid development (hopefully!:) for a while. Its gonna be a while
before all the recipes are totally finished & hardened; but I don't
see why they can't be released in a kinda work-in-progress state. e.g.
so long as we document that the recipe code may change in the future,
I don't see any issue including the recipe code along with the ZK
client and server in a single release. But down the line we could
always split it up if we need to.
I tend to prefer deferring decisions until we really need to and
saving work where possible (particularly when it comes to things like
doing releases); so for now I'd prefer to release the recipe's in the
Java ZK client/server release distro as a separate optional jar (along
with some warnings the recipe's are work in progress and might change
a little over the next few months as we figure out the neatest way to
implement the higher level protocols etc) plus separate documentation
stuff.
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
Re: Recipe contrib -- was Re: [PATCH] a simple Leader Election or
exclusive Write Lock protocol/policy
Posted by Doug Cutting <cu...@apache.org>.
Patrick Hunt wrote:
> We were thinking of contrib as "interesting stuff that users might want
> to re-use/share but not core to zookeeper, we'll carry it around so that
> users know where to find it, if it gets broken and no one fixes it it
> won't hold up the release"
That's a fine policy for contrib, roughly what Lucene, Hadoop etc. have.
The QA, documentation, etc. requirements for contrib are frequently
lower. The IP requirements however are equal, since Apache's
distributing the code.
Doug
Re: Recipe contrib -- was Re: [PATCH] a simple Leader Election or
exclusive Write Lock protocol/policy
Posted by Patrick Hunt <ph...@apache.org>.
Doug Cutting wrote:
> Patrick Hunt wrote:
>> my original intent was to have it as zookeeper/trunk/src/contrib/...
>> where this directory will have not only recipes but also other
>> contributions.
>
> +1 That's what I meant too. And since you've said you want to package
> these all as a single jar, then there should just be a single tree per
> language, right?
Yes, that's right.
>
> zookeeper/trunk/src/contrib/recipes/src/java/org/apache/zookeeper/recipes/locking/
> zookeeper/trunk/src/contrib/recipes/src/c++/locking/
>
Right.
> I don't see the strong connection between releases and new features.
....
> Am I missing something?
I think that the issue is implied connotation of "contrib".
We were thinking of contrib as "interesting stuff that users might want
to re-use/share but not core to zookeeper, we'll carry it around so that
users know where to find it, if it gets broken and no one fixes it it
won't hold up the release"
If I understand correctly you are saying there is no middle ground.
Patrick
Re: Recipe contrib -- was Re: [PATCH] a simple Leader Election or
exclusive Write Lock protocol/policy
Posted by Doug Cutting <cu...@apache.org>.
Patrick Hunt wrote:
> my original intent was to have it as zookeeper/trunk/src/contrib/...
> where this directory will have not only recipes but also other
> contributions.
+1 That's what I meant too. And since you've said you want to package
these all as a single jar, then there should just be a single tree per
language, right?
zookeeper/trunk/src/contrib/recipes/src/java/org/apache/zookeeper/recipes/locking/
zookeeper/trunk/src/contrib/recipes/src/c++/locking/
> What happens in this case then, you include them as part of ZK release
> or you have a separate "contrib" release? It seems to me that this could
> have a ripple effect - where contrib is causing regular releases to be
> held up.
If you release them separately from the ZK core then they're a separate
Apache product, and should then probably be not in zookeeper/trunk, but
in zookeeper-recipes/trunk, etc.
Why would they hold up a release?
> ZOOKEEPER-25 adds FUSE support, seems like we are going to have similar
> issues to face there. Is this a separate "release" from recipes or are
> all "contrib" considered to be a single release? What about when we add
> REST & scripting support thru contrib....
I don't see the strong connection between releases and new features.
Typically at some point you feature-freeze, branch, and call that
release series X. Then, at some later point, you feature-freeze again,
and call that release series Y. They'll have different features. X may
not include FUSE support, and Y may.
Or you could choose a different release discipline, and permit new
contrib features in a release series, but no new core features. Or
something else. But at some point you're going to roll up a bunch of
code into a binary and vote on it and call it a release of Zookeeper and
a product of Apache.
Am I missing something?
> Doug, is there any documentation that I could look at at Apache that
> would help? Guidelines/bestpractice for "contrib"?
Not that I know of. Analogous things are perhaps httpd modules, and
httpd is a very well run project.
Doug
Re: Recipe contrib -- was Re: [PATCH] a simple Leader Election or
exclusive Write Lock protocol/policy
Posted by Patrick Hunt <ph...@apache.org>.
Doug Cutting wrote:
> Patrick Hunt wrote:
>> 1) I think we should have a
>> "contrib/recipes/{java/{main,test}/org/apache/zookeeper/... ,c/,...}"
>> hierarchy for contributions that implement recipes, including any
>> helper code
>
> Are folks expected to be able to use this code as-is? Are these, in
> effect, libraries? If so, you might make each a separate contrib
> module, so they can be packaged as separate jars and folks can use them
> ala carte.
When you say "module" do you mean a contrib directory as a sibling to
zookeeper/trunk in SVN?
http://svn.apache.org/repos/asf/hadoop/zookeeper/
my original intent was to have it as zookeeper/trunk/src/contrib/...
where this directory will have not only recipes but also other
contributions.
>
>> 2) We should first document recipes on the wiki, then implement them
>> in the code
>> http://wiki.apache.org/hadoop/ZooKeeper/ZooKeeperRecipes
>> The code should fully document the api/implementation, and refer to
>> wiki page for protocol specifics.
>
> The wiki should not be used long-term for code documentation. It's a
> good documentation scratchpad, but for code that's released, the
> documentation should be versioned and released as well, and thus should
> live in subversion.
Agree, we should move the recipes from wiki to forrest.
>
>> 3) What should we do relative to ZK releases. Are recipes included in
>> a release? Will bugs in recipes hold up a release?
>>
>> My initial thought is that contrib is available through svn, but not
>> included in the release. If users want to access/use this code they
>> will be required to checkout/build themselves. (at least initially)
>
> Won't recipes change as ZK API's change? If so, then recipes should be
> versioned with releases. And if non-committers are expected to download
> recipes, then, legally, they should be released through an official
> release process. Stuff in svn isn't fully covered by the Apache
> license. Apache only vouches for stuff that's gone through an official
> release process. Subversion is for internal exchange by Apache of
> works-in-progress, not for end users.
Hrm. :-)
What happens in this case then, you include them as part of ZK release
or you have a separate "contrib" release? It seems to me that this could
have a ripple effect - where contrib is causing regular releases to be
held up.
ZOOKEEPER-25 adds FUSE support, seems like we are going to have similar
issues to face there. Is this a separate "release" from recipes or are
all "contrib" considered to be a single release? What about when we add
REST & scripting support thru contrib....
Doug, is there any documentation that I could look at at Apache that
would help? Guidelines/bestpractice for "contrib"?
Patrick
Re: Recipe contrib -- was Re: [PATCH] a simple Leader Election or
exclusive Write Lock protocol/policy
Posted by Doug Cutting <cu...@apache.org>.
Patrick Hunt wrote:
> 1) I think we should have a
> "contrib/recipes/{java/{main,test}/org/apache/zookeeper/... ,c/,...}"
> hierarchy for contributions that implement recipes, including any helper
> code
Are folks expected to be able to use this code as-is? Are these, in
effect, libraries? If so, you might make each a separate contrib
module, so they can be packaged as separate jars and folks can use them
ala carte.
> 2) We should first document recipes on the wiki, then implement them in
> the code
> http://wiki.apache.org/hadoop/ZooKeeper/ZooKeeperRecipes
> The code should fully document the api/implementation, and refer to wiki
> page for protocol specifics.
The wiki should not be used long-term for code documentation. It's a
good documentation scratchpad, but for code that's released, the
documentation should be versioned and released as well, and thus should
live in subversion.
> 3) What should we do relative to ZK releases. Are recipes included in a
> release? Will bugs in recipes hold up a release?
>
> My initial thought is that contrib is available through svn, but not
> included in the release. If users want to access/use this code they will
> be required to checkout/build themselves. (at least initially)
Won't recipes change as ZK API's change? If so, then recipes should be
versioned with releases. And if non-committers are expected to download
recipes, then, legally, they should be released through an official
release process. Stuff in svn isn't fully covered by the Apache
license. Apache only vouches for stuff that's gone through an official
release process. Subversion is for internal exchange by Apache of
works-in-progress, not for end users.
Doug
Re: Recipe contrib -- was Re: [PATCH] a simple Leader Election or exclusive Write Lock protocol/policy
Posted by James Strachan <ja...@gmail.com>.
It should be pretty easy to link together the various recipe's from
the site/wiki and where possible share the recipe documentation across
languages
2008/7/18 Benjamin Reed <br...@yahoo-inc.com>:
> Some initial implementations of a recipe may only be in C, so it would
> be nice to have a standard way of finding the recipe that wasn't
> dependent on the language that implements the recipe.
>
> ben
>
> James Strachan wrote:
>> 2008/7/17 Benjamin Reed <br...@yahoo-inc.com>:
>>
>>> Excellent proposal. The only thing I would add is that there should be
>>> an english description of the recipe in subversion. That way if someone
>>> wanted to do a compatible binding they can do it. If the recipe is on
>>> the wiki it would be hard to keep it in sync, so it is important that it
>>> is in subversion. My preference would be that the doc would be in the
>>> same contrib subdirectory as the source for ease of maintenance.
>>>
>>
>> Good idea. How about for Java recipe's we include the documentation as
>> HTML with the javadoc so we can link to it easily and so that the
>> recipe is kept with the code & versioned nicely (so as the
>> recipe/algorithm changes we version it with the source code etc)
>>
>>
>
>
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
Re: Recipe contrib -- was Re: [PATCH] a simple Leader Election or
exclusive Write Lock protocol/policy
Posted by Benjamin Reed <br...@yahoo-inc.com>.
Some initial implementations of a recipe may only be in C, so it would
be nice to have a standard way of finding the recipe that wasn't
dependent on the language that implements the recipe.
ben
James Strachan wrote:
> 2008/7/17 Benjamin Reed <br...@yahoo-inc.com>:
>
>> Excellent proposal. The only thing I would add is that there should be
>> an english description of the recipe in subversion. That way if someone
>> wanted to do a compatible binding they can do it. If the recipe is on
>> the wiki it would be hard to keep it in sync, so it is important that it
>> is in subversion. My preference would be that the doc would be in the
>> same contrib subdirectory as the source for ease of maintenance.
>>
>
> Good idea. How about for Java recipe's we include the documentation as
> HTML with the javadoc so we can link to it easily and so that the
> recipe is kept with the code & versioned nicely (so as the
> recipe/algorithm changes we version it with the source code etc)
>
>
Re: Recipe contrib -- was Re: [PATCH] a simple Leader Election or exclusive Write Lock protocol/policy
Posted by James Strachan <ja...@gmail.com>.
2008/7/17 Benjamin Reed <br...@yahoo-inc.com>:
> Excellent proposal. The only thing I would add is that there should be
> an english description of the recipe in subversion. That way if someone
> wanted to do a compatible binding they can do it. If the recipe is on
> the wiki it would be hard to keep it in sync, so it is important that it
> is in subversion. My preference would be that the doc would be in the
> same contrib subdirectory as the source for ease of maintenance.
Good idea. How about for Java recipe's we include the documentation as
HTML with the javadoc so we can link to it easily and so that the
recipe is kept with the code & versioned nicely (so as the
recipe/algorithm changes we version it with the source code etc)
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
Re: Recipe contrib -- was Re: [PATCH] a simple Leader Election or
exclusive Write Lock protocol/policy
Posted by Patrick Hunt <ph...@apache.org>.
I was thinking all the recipe implementations are in a single jar.
zookeeper-recipes.jar
otw it's going to be a pain to carry around the "right" jars - esp if
one recipe depends on another. We saw similar issue with Pig UDF
contribs (originally there were multiple jars).
Patrick
Doug Cutting wrote:
> Patrick Hunt wrote:
>> should we have separate contrib subdirs, one for each recipe or all
>> recipes together? What about shared code, common code for implementing
>> a recipe? Seems a little too much to separate them all at the top
>> level, rather than separating them in packages
>
> Do you want to package them together, in a single jar, or separately,
> each in their own jar? A tree per jar is standard.
>
> Doug
Re: Recipe contrib -- was Re: [PATCH] a simple Leader Election or
exclusive Write Lock protocol/policy
Posted by Doug Cutting <cu...@apache.org>.
Patrick Hunt wrote:
> should we have separate contrib subdirs, one for each recipe or all
> recipes together? What about shared code, common code for implementing a
> recipe? Seems a little too much to separate them all at the top level,
> rather than separating them in packages
Do you want to package them together, in a single jar, or separately,
each in their own jar? A tree per jar is standard.
Doug
Re: Recipe contrib -- was Re: [PATCH] a simple Leader Election or
exclusive Write Lock protocol/policy
Posted by Patrick Hunt <ph...@apache.org>.
I didn't get that from Ben's comment, I thought he was talking about
including the docs into contrib/recipes rather than in
trunk/src/docs/... (which makes sense to me, also makes sense in light
of doug's subsequent comments on this thread).
should we have separate contrib subdirs, one for each recipe or all
recipes together? What about shared code, common code for implementing a
recipe? Seems a little too much to separate them all at the top level,
rather than separating them in packages
contrib/recipes/java/main/org/apache/zookeeper/protocol/leaderelection
contrib/recipes/java/main/org/apache/zookeeper/protocol/locking
contrib/recipes/java/main/org/apache/zookeeper/protocol/utils
Patrick
Mahadev Konar wrote:
> I agree with Ben. Can we have something like?
>
> Contrib/recipes/leaderelection
> Or
> Contrib/recipes/locking/
>
> And a README inside each of these directories to explain what its doing?
>
>
> mahadev
>
>> -----Original Message-----
>> From: Benjamin Reed [mailto:breed@yahoo-inc.com]
>> Sent: Thursday, July 17, 2008 10:33 AM
>> To: zookeeper-dev@hadoop.apache.org
>> Subject: Re: Recipe contrib -- was Re: [PATCH] a simple Leader
> Election or
>> exclusive Write Lock protocol/policy
>>
>> Excellent proposal. The only thing I would add is that there should be
>> an english description of the recipe in subversion. That way if
> someone
>> wanted to do a compatible binding they can do it. If the recipe is on
>> the wiki it would be hard to keep it in sync, so it is important that
> it
>> is in subversion. My preference would be that the doc would be in the
>> same contrib subdirectory as the source for ease of maintenance.
>>
>> ben
>>
>> Patrick Hunt wrote:
>>> James, thanks for the contribution! Tests and everything. :-)
>>>
>>> Jacob sent some mail to the list recently (attached) that details a
>>> protocol that he's used successfully (and picked up by some zk
> users).
>>> I have a todo item to document this protocol on the recipes wiki
> page,
>>> haven't gotten to it yet. Not sure how/if this matches what you've
>>> done but we should sync up (also see below).
>>> https://issues.apache.org/jira/browse/ZOOKEEPER-79
>>>
>>> There has been some discussion on client side helper code in the
> past
>>> however this is the first contribution. We need to make some
> decisions
>>> and outline what/how we will accept.
>>>
>>> 1) I think we should have a
>>> "contrib/recipes/{java/{main,test}/org/apache/zookeeper/...
> ,c/,...}"
>>> hierarchy for contributions that implement recipes, including any
>>> helper code
>>>
>>> 2) We should first document recipes on the wiki, then implement them
>>> in the code
>>> http://wiki.apache.org/hadoop/ZooKeeper/ZooKeeperRecipes
>>> The code should fully document the api/implementation, and refer to
>>> wiki page for protocol specifics.
>>>
>>> 3) What should we do relative to ZK releases. Are recipes included
> in
>>> a release? Will bugs in recipes hold up a release?
>>>
>>> My initial thought is that contrib is available through svn, but not
>>> included in the release. If users want to access/use this code they
>>> will be required to checkout/build themselves. (at least initially)
>>>
>>> 4) We will not require "parody" btw the various client languages.
>>> Currently we support Java/C clients, we will be adding various
>>> scripting languages soon. Contributions will be submitted for
> various
>>> clients (James' submission is for java), that will be placed into
>>> contrib, if someone else contributes C bindings (etc...) we will add
>>> those to contrib/recipes as well.
>>>
>>> 5) Implementations should strive to implement similar recipe
> protocols
>>> (see 2 above, a good reason to document before implement). There may
>>> be multiple, different, protocols each with their own
> implementation,
>>> but for a particular protocol the implementations should be the
> same.
>>> We may want to stress 5 even more - if multiple clients
>>> implementations (c/java/...) are participating in a single instance
> of
>>> leader election it will be CRITICAL for them to be inter-operable.
>>>
>>>
>>> Comments, questions, suggestion?
>>>
>>> Patrick
>>>
>>> James Strachan wrote:
>>>> So having recently discovered ZooKeeper, I'm really liking it -
> good
>>>> job folks!
>>>>
>>>> I've seen discussions of building high level features from the core
> ZK
>>>> library and had not seen any available on the interweb so figured
> I'd
>>>> have a try creating a simple one. Feel free to ignore it if a ZK
> ninja
>>>> can think of a neater way of doing it - I've basically followed the
>>>> protocol defined in the recent ZK presentation...
>>>> http://developer.yahoo.com/blogs/hadoop/2008/03/intro-to-zookeeper-
>> video.html
>>>>
>>>> I've submitted the code as a patch here...
>>>> https://issues.apache.org/jira/browse/ZOOKEEPER-78
>>>>
>>>> I figured the Java Client might as well come with some helper code
> to
>>>> make doing things like exclusive locks or leader elections easier;
> we
>>>> could always spin them out into a separate library if and when
>>>> required etc. Right now its one fairly simple class :)
>>>>
>>>> Currently its a simple class where you can register a Runnable to
> be
>>>> invoked when you have the lock; or you can just keep asking if you
>>>> have the lock now and again as you see fit etc.
>>>>
>>>> WriteLock locker = new WriteLock(zookeeper, "/foo/bar");
>>>> locker.setWhenOwner(new Runnable() {...}); // fire this code when
>>>> owner...
>>>>
>>>> // lets try own it
>>>> locker.acquire();
>>>>
>>>> // I may or may not have the lock now
>>>> if (locker.isOwner()) {....}
>>>>
>>>> // time passes
>>>> locker.close();
>>>>
>>>>
>>>> Thoughts?
>>>>
>>>
> ------------------------------------------------------------------------
>>> Subject:
>>> Re: [Zookeeper-user] Leader election
>>> From:
>>> "Jacob Levy" <jy...@yahoo-inc.com>
>>> Date:
>>> Fri, 11 Jul 2008 10:42:33 -0700
>>> To:
>>> "Flavio Junqueira" <fp...@yahoo.com>,
>>> <zo...@lists.sourceforge.net>, <av...@gmail.com>
>>>
>>> To:
>>> "Flavio Junqueira" <fp...@yahoo.com>,
>>> <zo...@lists.sourceforge.net>, <av...@gmail.com>
>>> CC:
>>> zookeeper-user@hadoop.apache.org
>>>
>>>
>>> *Avinash*
>>>
>>>
>>>
>>> The following protocol will help you fix the observed misbehavior.
> As
>>> Flavio points out, you cannot rely on the order of nodes in
>>> getChildren, you must use an intrinsic property of each node to
>>> determine who is the leader. The protocol devised by Runping Qi and
>>> described here will do that.
>>>
>>>
>>>
>>> First of all, when you create child nodes of the node that holds the
>>> leadership bids, you must create them with the EPHEMERAL and
> SEQUENCE
>>> flag. ZooKeeper guarantees to give you an ephemeral node named
>>> uniquely and with a sequence number larger by at least one than any
>>> previously created node in the sequence. You provide a prefix, like
>>> "L_" or your own choice, and ZooKeeper creates nodes named "L_23",
>>> "L_24", etc. The sequence number starts at 0 and increases
> monotonously.
>>>
>>>
>>> Once you've placed your leadership bid, you search backwards from
> the
>>> sequence number of **your** node to see if there are any preceding
> (in
>>> terms of the sequence number) nodes. When you find one, you place a
>>> watch on it and wait for it to disappear. When you get the watch
>>> notification, you search again, until you do not find a preceding
>>> node, then you know you're the leader. This protocol guarantees that
>>> there is at any time only one node that thinks it is the leader. But
>>> it does not disseminate information about who is the leader. If you
>>> want everyone to know who is the leader, you can have an additional
>>> Znode whose value is the name of the current leader (or some
>>> identifying information on how to contact the leader, etc.). Note
> that
>>> this cannot be done atomically, so by the time other nodes find out
>>> who the leader is, the leadership may already have passed on to a
>>> different node.
>>>
>>>
>>>
>>> *Flavio*
>>>
>>>
>>>
>>> Might it make sense to provide a standardized implementation of
> leader
>>> election in the library code in Java?
>>>
>>>
>>>
>>> --Jacob
>>>
>>>
>>>
>>>
> ------------------------------------------------------------------------
>>> *From:* zookeeper-user-bounces@lists.sourceforge.net
>>> [mailto:zookeeper-user-bounces@lists.sourceforge.net] *On Behalf Of
>>> *Flavio Junqueira
>>> *Sent:* Friday, July 11, 2008 1:02 AM
>>> *To:* zookeeper-user@lists.sourceforge.net
>>> *Cc:* zookeeper-user@hadoop.apache.org
>>> *Subject:* Re: [Zookeeper-user] Leader election
>>>
>>>
>>>
>>> Hi Avinash, getChildren returns a list in lexicographic order, so if
>>> you are updating the children of the election node concurrently,
> then
>>> you may get a different first node with different clients. If you
> are
>>> using the sequence flag to create nodes, then you may consider
>>> stripping the prefix of the node name and using the sufix value to
>>> determine order.
>>>
>>> Hope it helps.
>>>
>>> -Flavio
>>>
>>>
>>>
>>> ----- Original Message ----
>>> From: Avinash Lakshman <av...@gmail.com>
>>> To: zookeeper-user@lists.sourceforge.net
>>> Sent: Friday, July 11, 2008 7:20:06 AM
>>> Subject: [Zookeeper-user] Leader election
>>>
>>> Hi
>>>
>>> I am trying to elect leader among 50 nodes. There is always one odd
>>> guy who seems to think that someone else distinct from what some
> other
>>> nodes see as leader. Could someone please tell me what is wrong with
>>> the following code for leader election:
>>>
>>> public void electLeader()
>>> {
>>> ZooKeeper zk =
>> StorageService.instance().getZooKeeperHandle();
>>> String path = "/Leader";
>>> try
>>> {
>>> String createPath = path +
>>> "/L-";
>>> LeaderElector.createLock_.lock();
>>> while( true )
>>> {
>>> /* Get all znodes under the Leader znode */
>>> List<String> values = zk.getChildren(path,
> false);
>>> /*
>>> * Get the first znode and if it is the
>>> * pathCreated created above then the data
>>> * in that znode is the leader's identity.
>>> */
>>> if ( leader_ == null )
>>> {
>>> leader_ = new AtomicReference<EndPoint>(
>>> EndPoint.fromBytes( zk.getData(path + "/" + values.get(0), false,
>>> null) ) );
>>> }
>>> else
>>> {
>>> leader_.set( EndPoint.fromBytes(
>>> zk.getData(path + "/" + values .get(0), false, null) ) );
>>> /* Disseminate the state as to who the
> leader
>>> is. */
>>> onLeaderElection();
>>> }
>>> logger_.debug("Elected leader is " + leader_ + "
> @
>>> znode " + ( path + "/" + values.get(0) ) );
>>> Collections.sort(values);
>>> /* We need only the last portion of this znode
> */
>>> String[] peices = pathCreated_.split("/");
>>> int index = Collections.binarySearch(values,
>>> peices[peices.length - 1]);
>>> if ( index > 0 )
>>> {
>>> String pathToCheck = path + "/" +
>>> values.get(index - 1);
>>> Stat stat = zk.exists(pathToCheck, true);
>>> if ( stat != null )
>>> {
>>> logger_.debug("Awaiting my turn ...");
>>> condition_.await();
>>> logger_.debug("Checking to see if leader
>>> is around ...");
>>> }
>>> }
>>> else
>>> {
>>> break;
>>> }
>>> }
>>> }
>>> catch ( InterruptedException ex )
>>> {
>>> logger_.warn(LogUtil.throwableToString(ex));
>>> }
>>> catch ( KeeperException ex )
>>> {
>>> logger_.warn(LogUtil.throwableToString(ex));
>>> }
>>> finally
>>> {
>>> LeaderElector.createLock_.unlock();
>>> }
>>> }
>>> }
>>>
>>> Thanks
>>> Avinash
>>>
>>>
>>>
>>>
> ------------------------------------------------------------------------
>>>
> ------------------------------------------------------------------------
>> -
>>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>>> Studies have shown that voting for your favorite open source
> project,
>>> along with a healthy diet, reduces your potential for chronic
> lameness
>>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>>>
> ------------------------------------------------------------------------
>>> _______________________________________________
>>> Zookeeper-user mailing list
>>> Zookeeper-user@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/zookeeper-user
>>>
>
RE: Recipe contrib -- was Re: [PATCH] a simple Leader Election or exclusive Write Lock protocol/policy
Posted by Mahadev Konar <ma...@yahoo-inc.com>.
I agree with Ben. Can we have something like?
Contrib/recipes/leaderelection
Or
Contrib/recipes/locking/
And a README inside each of these directories to explain what its doing?
mahadev
> -----Original Message-----
> From: Benjamin Reed [mailto:breed@yahoo-inc.com]
> Sent: Thursday, July 17, 2008 10:33 AM
> To: zookeeper-dev@hadoop.apache.org
> Subject: Re: Recipe contrib -- was Re: [PATCH] a simple Leader
Election or
> exclusive Write Lock protocol/policy
>
> Excellent proposal. The only thing I would add is that there should be
> an english description of the recipe in subversion. That way if
someone
> wanted to do a compatible binding they can do it. If the recipe is on
> the wiki it would be hard to keep it in sync, so it is important that
it
> is in subversion. My preference would be that the doc would be in the
> same contrib subdirectory as the source for ease of maintenance.
>
> ben
>
> Patrick Hunt wrote:
> > James, thanks for the contribution! Tests and everything. :-)
> >
> > Jacob sent some mail to the list recently (attached) that details a
> > protocol that he's used successfully (and picked up by some zk
users).
> > I have a todo item to document this protocol on the recipes wiki
page,
> > haven't gotten to it yet. Not sure how/if this matches what you've
> > done but we should sync up (also see below).
> > https://issues.apache.org/jira/browse/ZOOKEEPER-79
> >
> > There has been some discussion on client side helper code in the
past
> > however this is the first contribution. We need to make some
decisions
> > and outline what/how we will accept.
> >
> > 1) I think we should have a
> > "contrib/recipes/{java/{main,test}/org/apache/zookeeper/...
,c/,...}"
> > hierarchy for contributions that implement recipes, including any
> > helper code
> >
> > 2) We should first document recipes on the wiki, then implement them
> > in the code
> > http://wiki.apache.org/hadoop/ZooKeeper/ZooKeeperRecipes
> > The code should fully document the api/implementation, and refer to
> > wiki page for protocol specifics.
> >
> > 3) What should we do relative to ZK releases. Are recipes included
in
> > a release? Will bugs in recipes hold up a release?
> >
> > My initial thought is that contrib is available through svn, but not
> > included in the release. If users want to access/use this code they
> > will be required to checkout/build themselves. (at least initially)
> >
> > 4) We will not require "parody" btw the various client languages.
> > Currently we support Java/C clients, we will be adding various
> > scripting languages soon. Contributions will be submitted for
various
> > clients (James' submission is for java), that will be placed into
> > contrib, if someone else contributes C bindings (etc...) we will add
> > those to contrib/recipes as well.
> >
> > 5) Implementations should strive to implement similar recipe
protocols
> > (see 2 above, a good reason to document before implement). There may
> > be multiple, different, protocols each with their own
implementation,
> > but for a particular protocol the implementations should be the
same.
> >
> > We may want to stress 5 even more - if multiple clients
> > implementations (c/java/...) are participating in a single instance
of
> > leader election it will be CRITICAL for them to be inter-operable.
> >
> >
> > Comments, questions, suggestion?
> >
> > Patrick
> >
> > James Strachan wrote:
> >> So having recently discovered ZooKeeper, I'm really liking it -
good
> >> job folks!
> >>
> >> I've seen discussions of building high level features from the core
ZK
> >> library and had not seen any available on the interweb so figured
I'd
> >> have a try creating a simple one. Feel free to ignore it if a ZK
ninja
> >> can think of a neater way of doing it - I've basically followed the
> >> protocol defined in the recent ZK presentation...
> >> http://developer.yahoo.com/blogs/hadoop/2008/03/intro-to-zookeeper-
> video.html
> >>
> >>
> >> I've submitted the code as a patch here...
> >> https://issues.apache.org/jira/browse/ZOOKEEPER-78
> >>
> >> I figured the Java Client might as well come with some helper code
to
> >> make doing things like exclusive locks or leader elections easier;
we
> >> could always spin them out into a separate library if and when
> >> required etc. Right now its one fairly simple class :)
> >>
> >> Currently its a simple class where you can register a Runnable to
be
> >> invoked when you have the lock; or you can just keep asking if you
> >> have the lock now and again as you see fit etc.
> >>
> >> WriteLock locker = new WriteLock(zookeeper, "/foo/bar");
> >> locker.setWhenOwner(new Runnable() {...}); // fire this code when
> >> owner...
> >>
> >> // lets try own it
> >> locker.acquire();
> >>
> >> // I may or may not have the lock now
> >> if (locker.isOwner()) {....}
> >>
> >> // time passes
> >> locker.close();
> >>
> >>
> >> Thoughts?
> >>
> >
> >
------------------------------------------------------------------------
> >
> > Subject:
> > Re: [Zookeeper-user] Leader election
> > From:
> > "Jacob Levy" <jy...@yahoo-inc.com>
> > Date:
> > Fri, 11 Jul 2008 10:42:33 -0700
> > To:
> > "Flavio Junqueira" <fp...@yahoo.com>,
> > <zo...@lists.sourceforge.net>, <av...@gmail.com>
> >
> > To:
> > "Flavio Junqueira" <fp...@yahoo.com>,
> > <zo...@lists.sourceforge.net>, <av...@gmail.com>
> > CC:
> > zookeeper-user@hadoop.apache.org
> >
> >
> > *Avinash*
> >
> >
> >
> > The following protocol will help you fix the observed misbehavior.
As
> > Flavio points out, you cannot rely on the order of nodes in
> > getChildren, you must use an intrinsic property of each node to
> > determine who is the leader. The protocol devised by Runping Qi and
> > described here will do that.
> >
> >
> >
> > First of all, when you create child nodes of the node that holds the
> > leadership bids, you must create them with the EPHEMERAL and
SEQUENCE
> > flag. ZooKeeper guarantees to give you an ephemeral node named
> > uniquely and with a sequence number larger by at least one than any
> > previously created node in the sequence. You provide a prefix, like
> > "L_" or your own choice, and ZooKeeper creates nodes named "L_23",
> > "L_24", etc. The sequence number starts at 0 and increases
monotonously.
> >
> >
> >
> > Once you've placed your leadership bid, you search backwards from
the
> > sequence number of **your** node to see if there are any preceding
(in
> > terms of the sequence number) nodes. When you find one, you place a
> > watch on it and wait for it to disappear. When you get the watch
> > notification, you search again, until you do not find a preceding
> > node, then you know you're the leader. This protocol guarantees that
> > there is at any time only one node that thinks it is the leader. But
> > it does not disseminate information about who is the leader. If you
> > want everyone to know who is the leader, you can have an additional
> > Znode whose value is the name of the current leader (or some
> > identifying information on how to contact the leader, etc.). Note
that
> > this cannot be done atomically, so by the time other nodes find out
> > who the leader is, the leadership may already have passed on to a
> > different node.
> >
> >
> >
> > *Flavio*
> >
> >
> >
> > Might it make sense to provide a standardized implementation of
leader
> > election in the library code in Java?
> >
> >
> >
> > --Jacob
> >
> >
> >
> >
------------------------------------------------------------------------
> >
> > *From:* zookeeper-user-bounces@lists.sourceforge.net
> > [mailto:zookeeper-user-bounces@lists.sourceforge.net] *On Behalf Of
> > *Flavio Junqueira
> > *Sent:* Friday, July 11, 2008 1:02 AM
> > *To:* zookeeper-user@lists.sourceforge.net
> > *Cc:* zookeeper-user@hadoop.apache.org
> > *Subject:* Re: [Zookeeper-user] Leader election
> >
> >
> >
> > Hi Avinash, getChildren returns a list in lexicographic order, so if
> > you are updating the children of the election node concurrently,
then
> > you may get a different first node with different clients. If you
are
> > using the sequence flag to create nodes, then you may consider
> > stripping the prefix of the node name and using the sufix value to
> > determine order.
> >
> > Hope it helps.
> >
> > -Flavio
> >
> >
> >
> > ----- Original Message ----
> > From: Avinash Lakshman <av...@gmail.com>
> > To: zookeeper-user@lists.sourceforge.net
> > Sent: Friday, July 11, 2008 7:20:06 AM
> > Subject: [Zookeeper-user] Leader election
> >
> > Hi
> >
> > I am trying to elect leader among 50 nodes. There is always one odd
> > guy who seems to think that someone else distinct from what some
other
> > nodes see as leader. Could someone please tell me what is wrong with
> > the following code for leader election:
> >
> > public void electLeader()
> > {
> > ZooKeeper zk =
> StorageService.instance().getZooKeeperHandle();
> > String path = "/Leader";
> > try
> > {
> > String createPath = path +
> > "/L-";
> > LeaderElector.createLock_.lock();
> > while( true )
> > {
> > /* Get all znodes under the Leader znode */
> > List<String> values = zk.getChildren(path,
false);
> > /*
> > * Get the first znode and if it is the
> > * pathCreated created above then the data
> > * in that znode is the leader's identity.
> > */
> > if ( leader_ == null )
> > {
> > leader_ = new AtomicReference<EndPoint>(
> > EndPoint.fromBytes( zk.getData(path + "/" + values.get(0), false,
> > null) ) );
> > }
> > else
> > {
> > leader_.set( EndPoint.fromBytes(
> > zk.getData(path + "/" + values .get(0), false, null) ) );
> > /* Disseminate the state as to who the
leader
> > is. */
> > onLeaderElection();
> > }
> > logger_.debug("Elected leader is " + leader_ + "
@
> > znode " + ( path + "/" + values.get(0) ) );
> > Collections.sort(values);
> > /* We need only the last portion of this znode
*/
> > String[] peices = pathCreated_.split("/");
> > int index = Collections.binarySearch(values,
> > peices[peices.length - 1]);
> > if ( index > 0 )
> > {
> > String pathToCheck = path + "/" +
> > values.get(index - 1);
> > Stat stat = zk.exists(pathToCheck, true);
> > if ( stat != null )
> > {
> > logger_.debug("Awaiting my turn ...");
> > condition_.await();
> > logger_.debug("Checking to see if leader
> > is around ...");
> > }
> > }
> > else
> > {
> > break;
> > }
> > }
> > }
> > catch ( InterruptedException ex )
> > {
> > logger_.warn(LogUtil.throwableToString(ex));
> > }
> > catch ( KeeperException ex )
> > {
> > logger_.warn(LogUtil.throwableToString(ex));
> > }
> > finally
> > {
> > LeaderElector.createLock_.unlock();
> > }
> > }
> > }
> >
> > Thanks
> > Avinash
> >
> >
> >
> >
------------------------------------------------------------------------
> >
> >
------------------------------------------------------------------------
> -
> > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> > Studies have shown that voting for your favorite open source
project,
> > along with a healthy diet, reduces your potential for chronic
lameness
> > and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> >
------------------------------------------------------------------------
> >
> > _______________________________________________
> > Zookeeper-user mailing list
> > Zookeeper-user@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/zookeeper-user
> >
Re: Recipe contrib -- was Re: [PATCH] a simple Leader Election or
exclusive Write Lock protocol/policy
Posted by Patrick Hunt <ph...@apache.org>.
I've created a Jira for us to discuss/document this:
https://issues.apache.org/jira/browse/ZOOKEEPER-80
I will make 78/79 depend on this
78 is James' patch - may require some rework after 79/80 are finalized
79 is documentation of the leader election protocol that jacob outlined
Patrick
Benjamin Reed wrote:
> Excellent proposal. The only thing I would add is that there should be
> an english description of the recipe in subversion. That way if someone
> wanted to do a compatible binding they can do it. If the recipe is on
> the wiki it would be hard to keep it in sync, so it is important that it
> is in subversion. My preference would be that the doc would be in the
> same contrib subdirectory as the source for ease of maintenance.
>
> ben
>
> Patrick Hunt wrote:
>> James, thanks for the contribution! Tests and everything. :-)
>>
>> Jacob sent some mail to the list recently (attached) that details a
>> protocol that he's used successfully (and picked up by some zk users).
>> I have a todo item to document this protocol on the recipes wiki page,
>> haven't gotten to it yet. Not sure how/if this matches what you've
>> done but we should sync up (also see below).
>> https://issues.apache.org/jira/browse/ZOOKEEPER-79
>>
>> There has been some discussion on client side helper code in the past
>> however this is the first contribution. We need to make some decisions
>> and outline what/how we will accept.
>>
>> 1) I think we should have a
>> "contrib/recipes/{java/{main,test}/org/apache/zookeeper/... ,c/,...}"
>> hierarchy for contributions that implement recipes, including any
>> helper code
>>
>> 2) We should first document recipes on the wiki, then implement them
>> in the code
>> http://wiki.apache.org/hadoop/ZooKeeper/ZooKeeperRecipes
>> The code should fully document the api/implementation, and refer to
>> wiki page for protocol specifics.
>>
>> 3) What should we do relative to ZK releases. Are recipes included in
>> a release? Will bugs in recipes hold up a release?
>>
>> My initial thought is that contrib is available through svn, but not
>> included in the release. If users want to access/use this code they
>> will be required to checkout/build themselves. (at least initially)
>>
>> 4) We will not require "parody" btw the various client languages.
>> Currently we support Java/C clients, we will be adding various
>> scripting languages soon. Contributions will be submitted for various
>> clients (James' submission is for java), that will be placed into
>> contrib, if someone else contributes C bindings (etc...) we will add
>> those to contrib/recipes as well.
>>
>> 5) Implementations should strive to implement similar recipe protocols
>> (see 2 above, a good reason to document before implement). There may
>> be multiple, different, protocols each with their own implementation,
>> but for a particular protocol the implementations should be the same.
>>
>> We may want to stress 5 even more - if multiple clients
>> implementations (c/java/...) are participating in a single instance of
>> leader election it will be CRITICAL for them to be inter-operable.
>>
>>
>> Comments, questions, suggestion?
>>
>> Patrick
>>
>> James Strachan wrote:
>>> So having recently discovered ZooKeeper, I'm really liking it - good
>>> job folks!
>>>
>>> I've seen discussions of building high level features from the core ZK
>>> library and had not seen any available on the interweb so figured I'd
>>> have a try creating a simple one. Feel free to ignore it if a ZK ninja
>>> can think of a neater way of doing it - I've basically followed the
>>> protocol defined in the recent ZK presentation...
>>> http://developer.yahoo.com/blogs/hadoop/2008/03/intro-to-zookeeper-video.html
>>>
>>>
>>> I've submitted the code as a patch here...
>>> https://issues.apache.org/jira/browse/ZOOKEEPER-78
>>>
>>> I figured the Java Client might as well come with some helper code to
>>> make doing things like exclusive locks or leader elections easier; we
>>> could always spin them out into a separate library if and when
>>> required etc. Right now its one fairly simple class :)
>>>
>>> Currently its a simple class where you can register a Runnable to be
>>> invoked when you have the lock; or you can just keep asking if you
>>> have the lock now and again as you see fit etc.
>>>
>>> WriteLock locker = new WriteLock(zookeeper, "/foo/bar");
>>> locker.setWhenOwner(new Runnable() {...}); // fire this code when
>>> owner...
>>>
>>> // lets try own it
>>> locker.acquire();
>>>
>>> // I may or may not have the lock now
>>> if (locker.isOwner()) {....}
>>>
>>> // time passes
>>> locker.close();
>>>
>>>
>>> Thoughts?
>>>
>> ------------------------------------------------------------------------
>>
>> Subject:
>> Re: [Zookeeper-user] Leader election
>> From:
>> "Jacob Levy" <jy...@yahoo-inc.com>
>> Date:
>> Fri, 11 Jul 2008 10:42:33 -0700
>> To:
>> "Flavio Junqueira" <fp...@yahoo.com>,
>> <zo...@lists.sourceforge.net>, <av...@gmail.com>
>>
>> To:
>> "Flavio Junqueira" <fp...@yahoo.com>,
>> <zo...@lists.sourceforge.net>, <av...@gmail.com>
>> CC:
>> zookeeper-user@hadoop.apache.org
>>
>>
>> *Avinash*
>>
>>
>>
>> The following protocol will help you fix the observed misbehavior. As
>> Flavio points out, you cannot rely on the order of nodes in
>> getChildren, you must use an intrinsic property of each node to
>> determine who is the leader. The protocol devised by Runping Qi and
>> described here will do that.
>>
>>
>>
>> First of all, when you create child nodes of the node that holds the
>> leadership bids, you must create them with the EPHEMERAL and SEQUENCE
>> flag. ZooKeeper guarantees to give you an ephemeral node named
>> uniquely and with a sequence number larger by at least one than any
>> previously created node in the sequence. You provide a prefix, like
>> "L_" or your own choice, and ZooKeeper creates nodes named "L_23",
>> "L_24", etc. The sequence number starts at 0 and increases monotonously.
>>
>>
>>
>> Once you've placed your leadership bid, you search backwards from the
>> sequence number of **your** node to see if there are any preceding (in
>> terms of the sequence number) nodes. When you find one, you place a
>> watch on it and wait for it to disappear. When you get the watch
>> notification, you search again, until you do not find a preceding
>> node, then you know you're the leader. This protocol guarantees that
>> there is at any time only one node that thinks it is the leader. But
>> it does not disseminate information about who is the leader. If you
>> want everyone to know who is the leader, you can have an additional
>> Znode whose value is the name of the current leader (or some
>> identifying information on how to contact the leader, etc.). Note that
>> this cannot be done atomically, so by the time other nodes find out
>> who the leader is, the leadership may already have passed on to a
>> different node.
>>
>>
>>
>> *Flavio*
>>
>>
>>
>> Might it make sense to provide a standardized implementation of leader
>> election in the library code in Java?
>>
>>
>>
>> --Jacob
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> *From:* zookeeper-user-bounces@lists.sourceforge.net
>> [mailto:zookeeper-user-bounces@lists.sourceforge.net] *On Behalf Of
>> *Flavio Junqueira
>> *Sent:* Friday, July 11, 2008 1:02 AM
>> *To:* zookeeper-user@lists.sourceforge.net
>> *Cc:* zookeeper-user@hadoop.apache.org
>> *Subject:* Re: [Zookeeper-user] Leader election
>>
>>
>>
>> Hi Avinash, getChildren returns a list in lexicographic order, so if
>> you are updating the children of the election node concurrently, then
>> you may get a different first node with different clients. If you are
>> using the sequence flag to create nodes, then you may consider
>> stripping the prefix of the node name and using the sufix value to
>> determine order.
>>
>> Hope it helps.
>>
>> -Flavio
>>
>>
>>
>> ----- Original Message ----
>> From: Avinash Lakshman <av...@gmail.com>
>> To: zookeeper-user@lists.sourceforge.net
>> Sent: Friday, July 11, 2008 7:20:06 AM
>> Subject: [Zookeeper-user] Leader election
>>
>> Hi
>>
>> I am trying to elect leader among 50 nodes. There is always one odd
>> guy who seems to think that someone else distinct from what some other
>> nodes see as leader. Could someone please tell me what is wrong with
>> the following code for leader election:
>>
>> public void electLeader()
>> {
>> ZooKeeper zk = StorageService.instance().getZooKeeperHandle();
>> String path = "/Leader";
>> try
>> {
>> String createPath = path +
>> "/L-";
>> LeaderElector.createLock_.lock();
>> while( true )
>> {
>> /* Get all znodes under the Leader znode */
>> List<String> values = zk.getChildren(path, false);
>> /*
>> * Get the first znode and if it is the
>> * pathCreated created above then the data
>> * in that znode is the leader's identity.
>> */
>> if ( leader_ == null )
>> {
>> leader_ = new AtomicReference<EndPoint>(
>> EndPoint.fromBytes( zk.getData(path + "/" + values.get(0), false,
>> null) ) );
>> }
>> else
>> {
>> leader_.set( EndPoint.fromBytes(
>> zk.getData(path + "/" + values .get(0), false, null) ) );
>> /* Disseminate the state as to who the leader
>> is. */
>> onLeaderElection();
>> }
>> logger_.debug("Elected leader is " + leader_ + " @
>> znode " + ( path + "/" + values.get(0) ) );
>> Collections.sort(values);
>> /* We need only the last portion of this znode */
>> String[] peices = pathCreated_.split("/");
>> int index = Collections.binarySearch(values,
>> peices[peices.length - 1]);
>> if ( index > 0 )
>> {
>> String pathToCheck = path + "/" +
>> values.get(index - 1);
>> Stat stat = zk.exists(pathToCheck, true);
>> if ( stat != null )
>> {
>> logger_.debug("Awaiting my turn ...");
>> condition_.await();
>> logger_.debug("Checking to see if leader
>> is around ...");
>> }
>> }
>> else
>> {
>> break;
>> }
>> }
>> }
>> catch ( InterruptedException ex )
>> {
>> logger_.warn(LogUtil.throwableToString(ex));
>> }
>> catch ( KeeperException ex )
>> {
>> logger_.warn(LogUtil.throwableToString(ex));
>> }
>> finally
>> {
>> LeaderElector.createLock_.unlock();
>> }
>> }
>> }
>>
>> Thanks
>> Avinash
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Zookeeper-user mailing list
>> Zookeeper-user@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/zookeeper-user
>>
>
>
Re: Recipe contrib -- was Re: [PATCH] a simple Leader Election or
exclusive Write Lock protocol/policy
Posted by Benjamin Reed <br...@yahoo-inc.com>.
Excellent proposal. The only thing I would add is that there should be
an english description of the recipe in subversion. That way if someone
wanted to do a compatible binding they can do it. If the recipe is on
the wiki it would be hard to keep it in sync, so it is important that it
is in subversion. My preference would be that the doc would be in the
same contrib subdirectory as the source for ease of maintenance.
ben
Patrick Hunt wrote:
> James, thanks for the contribution! Tests and everything. :-)
>
> Jacob sent some mail to the list recently (attached) that details a
> protocol that he's used successfully (and picked up by some zk users).
> I have a todo item to document this protocol on the recipes wiki page,
> haven't gotten to it yet. Not sure how/if this matches what you've
> done but we should sync up (also see below).
> https://issues.apache.org/jira/browse/ZOOKEEPER-79
>
> There has been some discussion on client side helper code in the past
> however this is the first contribution. We need to make some decisions
> and outline what/how we will accept.
>
> 1) I think we should have a
> "contrib/recipes/{java/{main,test}/org/apache/zookeeper/... ,c/,...}"
> hierarchy for contributions that implement recipes, including any
> helper code
>
> 2) We should first document recipes on the wiki, then implement them
> in the code
> http://wiki.apache.org/hadoop/ZooKeeper/ZooKeeperRecipes
> The code should fully document the api/implementation, and refer to
> wiki page for protocol specifics.
>
> 3) What should we do relative to ZK releases. Are recipes included in
> a release? Will bugs in recipes hold up a release?
>
> My initial thought is that contrib is available through svn, but not
> included in the release. If users want to access/use this code they
> will be required to checkout/build themselves. (at least initially)
>
> 4) We will not require "parody" btw the various client languages.
> Currently we support Java/C clients, we will be adding various
> scripting languages soon. Contributions will be submitted for various
> clients (James' submission is for java), that will be placed into
> contrib, if someone else contributes C bindings (etc...) we will add
> those to contrib/recipes as well.
>
> 5) Implementations should strive to implement similar recipe protocols
> (see 2 above, a good reason to document before implement). There may
> be multiple, different, protocols each with their own implementation,
> but for a particular protocol the implementations should be the same.
>
> We may want to stress 5 even more - if multiple clients
> implementations (c/java/...) are participating in a single instance of
> leader election it will be CRITICAL for them to be inter-operable.
>
>
> Comments, questions, suggestion?
>
> Patrick
>
> James Strachan wrote:
>> So having recently discovered ZooKeeper, I'm really liking it - good
>> job folks!
>>
>> I've seen discussions of building high level features from the core ZK
>> library and had not seen any available on the interweb so figured I'd
>> have a try creating a simple one. Feel free to ignore it if a ZK ninja
>> can think of a neater way of doing it - I've basically followed the
>> protocol defined in the recent ZK presentation...
>> http://developer.yahoo.com/blogs/hadoop/2008/03/intro-to-zookeeper-video.html
>>
>>
>> I've submitted the code as a patch here...
>> https://issues.apache.org/jira/browse/ZOOKEEPER-78
>>
>> I figured the Java Client might as well come with some helper code to
>> make doing things like exclusive locks or leader elections easier; we
>> could always spin them out into a separate library if and when
>> required etc. Right now its one fairly simple class :)
>>
>> Currently its a simple class where you can register a Runnable to be
>> invoked when you have the lock; or you can just keep asking if you
>> have the lock now and again as you see fit etc.
>>
>> WriteLock locker = new WriteLock(zookeeper, "/foo/bar");
>> locker.setWhenOwner(new Runnable() {...}); // fire this code when
>> owner...
>>
>> // lets try own it
>> locker.acquire();
>>
>> // I may or may not have the lock now
>> if (locker.isOwner()) {....}
>>
>> // time passes
>> locker.close();
>>
>>
>> Thoughts?
>>
>
> ------------------------------------------------------------------------
>
> Subject:
> Re: [Zookeeper-user] Leader election
> From:
> "Jacob Levy" <jy...@yahoo-inc.com>
> Date:
> Fri, 11 Jul 2008 10:42:33 -0700
> To:
> "Flavio Junqueira" <fp...@yahoo.com>,
> <zo...@lists.sourceforge.net>, <av...@gmail.com>
>
> To:
> "Flavio Junqueira" <fp...@yahoo.com>,
> <zo...@lists.sourceforge.net>, <av...@gmail.com>
> CC:
> zookeeper-user@hadoop.apache.org
>
>
> *Avinash*
>
>
>
> The following protocol will help you fix the observed misbehavior. As
> Flavio points out, you cannot rely on the order of nodes in
> getChildren, you must use an intrinsic property of each node to
> determine who is the leader. The protocol devised by Runping Qi and
> described here will do that.
>
>
>
> First of all, when you create child nodes of the node that holds the
> leadership bids, you must create them with the EPHEMERAL and SEQUENCE
> flag. ZooKeeper guarantees to give you an ephemeral node named
> uniquely and with a sequence number larger by at least one than any
> previously created node in the sequence. You provide a prefix, like
> "L_" or your own choice, and ZooKeeper creates nodes named "L_23",
> "L_24", etc. The sequence number starts at 0 and increases monotonously.
>
>
>
> Once you've placed your leadership bid, you search backwards from the
> sequence number of **your** node to see if there are any preceding (in
> terms of the sequence number) nodes. When you find one, you place a
> watch on it and wait for it to disappear. When you get the watch
> notification, you search again, until you do not find a preceding
> node, then you know you're the leader. This protocol guarantees that
> there is at any time only one node that thinks it is the leader. But
> it does not disseminate information about who is the leader. If you
> want everyone to know who is the leader, you can have an additional
> Znode whose value is the name of the current leader (or some
> identifying information on how to contact the leader, etc.). Note that
> this cannot be done atomically, so by the time other nodes find out
> who the leader is, the leadership may already have passed on to a
> different node.
>
>
>
> *Flavio*
>
>
>
> Might it make sense to provide a standardized implementation of leader
> election in the library code in Java?
>
>
>
> --Jacob
>
>
>
> ------------------------------------------------------------------------
>
> *From:* zookeeper-user-bounces@lists.sourceforge.net
> [mailto:zookeeper-user-bounces@lists.sourceforge.net] *On Behalf Of
> *Flavio Junqueira
> *Sent:* Friday, July 11, 2008 1:02 AM
> *To:* zookeeper-user@lists.sourceforge.net
> *Cc:* zookeeper-user@hadoop.apache.org
> *Subject:* Re: [Zookeeper-user] Leader election
>
>
>
> Hi Avinash, getChildren returns a list in lexicographic order, so if
> you are updating the children of the election node concurrently, then
> you may get a different first node with different clients. If you are
> using the sequence flag to create nodes, then you may consider
> stripping the prefix of the node name and using the sufix value to
> determine order.
>
> Hope it helps.
>
> -Flavio
>
>
>
> ----- Original Message ----
> From: Avinash Lakshman <av...@gmail.com>
> To: zookeeper-user@lists.sourceforge.net
> Sent: Friday, July 11, 2008 7:20:06 AM
> Subject: [Zookeeper-user] Leader election
>
> Hi
>
> I am trying to elect leader among 50 nodes. There is always one odd
> guy who seems to think that someone else distinct from what some other
> nodes see as leader. Could someone please tell me what is wrong with
> the following code for leader election:
>
> public void electLeader()
> {
> ZooKeeper zk = StorageService.instance().getZooKeeperHandle();
> String path = "/Leader";
> try
> {
> String createPath = path +
> "/L-";
> LeaderElector.createLock_.lock();
> while( true )
> {
> /* Get all znodes under the Leader znode */
> List<String> values = zk.getChildren(path, false);
> /*
> * Get the first znode and if it is the
> * pathCreated created above then the data
> * in that znode is the leader's identity.
> */
> if ( leader_ == null )
> {
> leader_ = new AtomicReference<EndPoint>(
> EndPoint.fromBytes( zk.getData(path + "/" + values.get(0), false,
> null) ) );
> }
> else
> {
> leader_.set( EndPoint.fromBytes(
> zk.getData(path + "/" + values .get(0), false, null) ) );
> /* Disseminate the state as to who the leader
> is. */
> onLeaderElection();
> }
> logger_.debug("Elected leader is " + leader_ + " @
> znode " + ( path + "/" + values.get(0) ) );
> Collections.sort(values);
> /* We need only the last portion of this znode */
> String[] peices = pathCreated_.split("/");
> int index = Collections.binarySearch(values,
> peices[peices.length - 1]);
> if ( index > 0 )
> {
> String pathToCheck = path + "/" +
> values.get(index - 1);
> Stat stat = zk.exists(pathToCheck, true);
> if ( stat != null )
> {
> logger_.debug("Awaiting my turn ...");
> condition_.await();
> logger_.debug("Checking to see if leader
> is around ...");
> }
> }
> else
> {
> break;
> }
> }
> }
> catch ( InterruptedException ex )
> {
> logger_.warn(LogUtil.throwableToString(ex));
> }
> catch ( KeeperException ex )
> {
> logger_.warn(LogUtil.throwableToString(ex));
> }
> finally
> {
> LeaderElector.createLock_.unlock();
> }
> }
> }
>
> Thanks
> Avinash
>
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> ------------------------------------------------------------------------
>
> _______________________________________________
> Zookeeper-user mailing list
> Zookeeper-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/zookeeper-user
>