zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Reed <br...@yahoo-inc.com>
Subject RE: Not performing work in the zookeeper even thread.
Date Mon, 05 Jan 2009 22:16:49 GMT
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: burtonator@gmail.com [burtonator@gmail.com] On Behalf Of Kevin Burton [burton@spinn3r.com]
Sent: Monday, January 05, 2009 2:08 PM
To: zookeeper-user@hadoop.apache.org
Subject: Re: Not performing work in the zookeeper even thread.

On Mon, Jan 5, 2009 at 1:23 PM, Benjamin Reed <breed@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
across threads?

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).

Founder/CEO Spinn3r.com
Location: San Francisco, CA
AIM/YIM: sfburtonator
Skype: burtonator
Work: http://spinn3r.com

View raw message