zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: Barrier Tutorial Possible Deadlock
Date Sun, 08 May 2011 20:48:43 GMT
These options have been considered, but are considered to be error-prone for
several reasons.

The problem with the TCP model is that it either establishes back-pressure
into the ZK servers or requires unreliable delivery mechanisms.  The first
option is completely unacceptable and the second is just a form of what we
have now wherein the application has to look at state after getting the

So the conclusion is that we don't want to pretend that the client will be
able to keep up with all notifications.

Once you have that conclusion, then it makes sense to not have permanent
watches.  Having transient watches as we do now provides automatic metering
of the flood from the server since the watch will not be reset until the
client gets around handling the event.

Also, giving up on complete delivery of all events means that we have to
relinquish the idea of event handling and switch to state handling with
change notification.

These finally lead to the model that ZK has right now.

Ben relates stories about how he started with passing the data with the
notifications, but he repeatedly saw cases where programmers used that data
as if it were authoritative (which it cannot be) and repeatedly wrote code
with bad race conditions because they used the stale data in the
notification and set the new watch against the current state.  This led to
data loss because of the gap between the data and when the new watch was

On Sun, May 8, 2011 at 1:14 PM, Justin Bailey <jbtechie@gmail.com> wrote:

> To any developers out there, how difficult would it be to customize the ZK
> code to both send data along with notifications and to have permanent
> watchers?  This would allow notifications for all changes to be guaranteed,
> sacrificing latency.  Having both options would be analogous to having both
> TCP and UDP protocols available for use depending on the particular
> requirements of the application.

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