I'm not sure what your Watcher:ZooKeeper notation means, but just to be clear:
each ZooKeeper object has an event thread with a corresponding event queue.
Whenever zookeeper needs to do a callback it queues the callback to the event
thread to handle the invocation.
From: burtona...@gmail.com [burtona...@gmail.com] On Behalf Of Kevin Burton
Sent: Monday, January 05, 2009 2:08 PM
Subject: Re: Not performing work in the zookeeper even thread.
On Mon, Jan 5, 2009 at 1:23 PM, Benjamin Reed <br...@yahoo-inc.com> wrote:
> the event thread is the client's own thread. zookeeper queues events to the
> event thread so that it doesn't have to worry about a backlog.
So each Watcher:ZooKeeper shares one thread (I was thinking you might be
doing this)? Wouldn't this be problematic when pooling ZooKeeper objects
I implemented a new API which I think is a bit easier to use than the ZK API
(I'll publish the source in a bit).
I had it implement a watchNode() method which registers an event. Then your
thread calls poll() which handles all events from ZK...
the API then blocks and waits for ZK to add events to its own internal
This way you can have a fully event driven application but you don't have to
worry about object corruption or threading issues.
> even if an application is slow in processing callbacks from the event
> thread, the rest of zookeeper (the heartbeats, the synchronous calls, etc.)
> will not be adversely affected.
OK... so even in multithreaded applications if you block you can't kill ZK
(which would be bad).
Location: San Francisco, CA