zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Burton" <bur...@spinn3r.com>
Subject Simpler ZooKeeper event interface....
Date Tue, 06 Jan 2009 17:26:29 GMT
Hey guys.

I think I'm finally in the position to push ZK into production for a while
to test it out.

My biggest feedback (other than the small bugs I found) was that the API
could be a bit simpler.

I codified my thoughts here:


Basically, I was thinking that one could receive an onData event to receive
the initial value.

Then all future events would call onData.....

I was thinking that an onExists() method might also be nice.

The current API could be made cleaner with:

 - one or two standalone Listener interfaces with onFoo methods for each
event type.
 - the processResults() method is the same for each interface right now
which is somewhat confusing.  Using onFoo is more self documenting.
 - using the main thread by using poll() to wait for events from ZooKeeper.
I use a ConcurrentLinkedQueue in my implementation.

Also, is there a race condition between when the client receives an event
for an update and before it can request a new one?  I was thinking session
local based events would solve this problem (you register your watch once
per session and then get all events until it is unregistered).

I think this can be solved in my code by reading the current version of the
value from the getData() method I call when I register the new watch and
comparing it to the last version I saw. If it was incremented then I would
call onData again.

The problem here is that I might miss two updates (but at least I would
receive the last stable value).


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message