In general, writing this sort of layer on top of ZK is very, very hard to
get really right for general use.  In a simple use-case, you can probably
nail it but distributed systems are a Zoo, to coin a phrase.  The problem is
that you are fundamentally changing the metaphors in use so assumptions can
come unglued or be introduced pretty easily.

One example of this is the fact that ZK watches *don't* fire for every
change but when you write listener oriented code, you kind of expect that
they will.  That makes it really, really easy to introduce that assumption
in the heads of the programmer using the event listener library on top of
ZK.  Another example is how the atomic get content/set watch call works in
ZK is easy to violate in an event driven architecture because the thread
that watches ZK probably resets the watch.  If you assume that the listener
will read the data, then you have introduced a timing mismatch between the
read of the data and the resetting of the watch.  That might be OK or it
might not be.  The point is that these changes are subtle and tricky to get
exactly right.

On Tue, May 4, 2010 at 1:48 PM, Jonathan Holloway <
jonathan.hollo...@gmail.com> wrote:

> Is there any reason why this isn't part of the Zookeeper trunk already?
>

Reply via email to