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,
:) . 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:44 AM, Kevin Burton bur...@spinn3r.com wrote:
OK so it sounds from the group that there are still reasons
On Wed, Jan 7, 2009 at 9:25 AM, Benjamin Reed br...@yahoo-inc.com wrote:
This is the behavior we had when we first implemented the API, and in every
case where people used the information there was a bug. it is virtually
impossible to use correctly. In general I'm all for giving people rope,
:
The version of Jute we use is really an ancient version of recordio
ser/deser library in hadoop. We do want to move to some
better(versioned/fast/well accepted) ser/deser library.
mahadev
On 1/7/09 12:08 PM, Kevin Burton bur...@spinn3r.com wrote:
Ah... you think it was because it was empty
I have an event watching a file... and if I restart the server I get this:
onConnect
onData path: /foo, version: 4, data: '2333'
onDisconnect
onConnect
onData path: /foo, version: 4, data: '2333'
It re-issues the same version of the file. I can of course watch for this in
my code but it seems
are stored locally on a particlar an server, etc)
On Jan 5, 2009, at 12:03 AM, Kevin Burton bur...@spinn3r.com wrote:
I'm not observing this behavior... if I shutdown the zookeeper server my
client doesn't reconnect and I get a disconnect event followed by
eventual
session expiration.
Which
Shutting down my zookeeper server yields this on my client.
Continual disconnect events.
Shouldn't only one be issued? The second one is not a state change.
WatchedEvent: Server state change. New state: Disconnected
WatchedEvent: Server state change. New state: Disconnected
WatchedEvent:
Because watches are one time triggers and there is latency between getting
the
event and sending a new request to get a watch you cannot reliably see
every
change that happens to a node in ZooKeeper. Be prepared to handle the case
where
the znode changes multiple times between getting the
