yeah, i was thinking it should be in forrest, but i couldn't figure out where
to put it. that is why i didn't close the issue.
ben
-Original Message-
From: Patrick Hunt [mailto:ph...@apache.org]
Sent: Friday, January 09, 2009 9:37 AM
To: zookeeper-user@hadoop.apache.org
Subject: Re: Upd
Well if that were the direction, goal, I'd feel more comfortable about
recommending ZK..
If a company were to implement some of these algorithms then I suspect
they'd run into a race condition, etc with all that rope.
For my part I'd be willing to contribute the NodeWatcher/NodeListener I
wrot
Hi Kevin,
It would be great to have such high level interfaces. It could be
something that you could contribute :) . We havent had the bandwidth to
provide such interfaces for zookeeper. It would be great to have all such
recipes as a part of contrib package of zookeeper.
mahadev
On 1/9/09 11:
OK so it sounds from the group that there are still reasons to provide
rope in ZK to enable algorithms like leader election.
Couldn't ZK ship higher level interfaces for leader election, mutexes,
semapores, queues, barriers, etc instead of pushing this on developers?
Then the remaining APIs, c
Thanks. And yes, your chart is really ugly! :)
These are the states of... what? The session? The ZooKeeper object? It
would be nice to include the corresponding API references.
.. Adam
On Fri, Jan 9, 2009 at 5:09 AM, Benjamin Reed wrote:
> I'm really bad a creating figures, but i've put up some
I've really wanted @threadsafe for a while for methods that are safe so
that you can have compiler errors when calling non-threadsafe APIs.
Kevin
On Fri, Jan 9, 2009 at 8:08 AM, Benjamin Reed wrote:
> yes, that is a good article. it is actually the one we used to decide about
> the current way
Ben this is great, thanks! Do you want to close out this one and point
to the faq?
https://issues.apache.org/jira/browse/ZOOKEEPER-264
Although IMO this should be moved to the forrest docs.
Patrick
Benjamin Reed wrote:
I'm really bad a creating figures, but i've put up something that should
In the case of an active leader, L continues to send commands
(whatever) to the followers. However a new leader L' has since been
elected and is also sending commands to the followers. In this case
it seems like either a) L should not send commands if it's not
sync'd to the ensemble (and ho
yes, that is a good article. it is actually the one we used to decide about the
current way of handling InterruptedException. in retrospect it turns out to be
a nice way to document that a call is blocking.
ben
-Original Message-
From: thomas.john...@sun.com [mailto:thomas.john...@sun.c
Kevin Burton wrote:
On Thu, Jan 8, 2009 at 3:21 PM, Benjamin Reed wrote:
InterruptedException is rather tricky because the semantics of
Thread.isInterrupted() is rather vague. specifically, it is unclear why
someone would interrupt a thread. usually Thread.interrupt() is used to shut
things
I'm really bad a creating figures, but i've put up something that should be
informative. (i'm also really bad at apache wiki.) hopefully someone can make
it more beautiful. i've added the state diagram to the FAQ:
http://wiki.apache.org/hadoop/ZooKeeper/FAQ
ben
-Original Message-
From:
11 matches
Mail list logo
