Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
Received-SPF: pass (athena.apache.org: domain of ted.dunning@gmail.com
 designates 209.85.220.170 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=BkdIgLIHKxbvz5hl4Zh7L4nqY9TO+HnGo1uilWuGz3mtn3GUjH6ffTdTx68POaDxdu
         Eq3/GpHIVtbPClo8RkoUsbiYKRkvQymnJ8KSSrg/y9bA6VDYiWa9M8lShnHCKAAIQrPb
         qnD+xuYIL4XCZH6lscmeFe5WcTRgd3EFA+XvE=
MIME-Version: 1.0
In-Reply-To: <4DC6F9AB.6000009@gmail.com>
References: <4DC6F9AB.6000009@gmail.com>
From: Ted Dunning <ted.dunning@gmail.com>
Date: Sun, 8 May 2011 13:48:43 -0700
Message-ID: <BANLkTik2eMYvc9hk08Gv2SXz1=Wr-6+QNw@mail.gmail.com>
Subject: Re: Barrier Tutorial Possible Deadlock
To: user@zookeeper.apache.org
Content-Type: multipart/alternative; boundary=20cf307f3b5c69395704a2c9da77

--20cf307f3b5c69395704a2c9da77
Content-Type: text/plain; charset=UTF-8

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

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


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

--20cf307f3b5c69395704a2c9da77--