Re: [Zookeeper-user] [Bug?] Notification not guaranteed

[Bartlomiej N. <ba...@ya...>]

That is not true, see Mahadev's reply.

Bart

-----Original Message-----
From: Ted Dunning [mailto:tdu...@ve...] 
Sent: Friday, April 25, 2008 11:59 AM
To: Bartlomiej Niechwiej; Benjamin Reed
Cc: zoo...@li...
Subject: Re: [Zookeeper-user] [Bug?] Notification not guaranteed


If you watch the parent, there are no race conditions.  Each time the
/alive
appears or disappears, you get an event.  The watch would go onto a stat
or
getContents call.  If the state changes at high frequency, you won't get
called every time, but you will always get valid data (for some point in
time) and you will never lose a notification.  The guarantee is that
after
every state change, the watcher will look to see what happened, but the
watcher may not look exactly once for every state change.  For most
applications this modified guarantee is actually better ... you don't
care
about the entire intricate evolution, you just want to get up to date.


Client side is actually better for this because the client knows best
what
it wants and can re-establish watches on connection loss.


On 4/25/08 11:47 AM, "Bartlomiej Niechwiej" <ba...@ya...> wrote:

> Now wait, I hear all of you screaming - race conditions, what? Oh
well,
> the point is when the process dies at frequency which is much higher
> that the ZK throughput, we may lose some important transitions from
> "/alive (present)" <-> "/ (absent)", also regarding (2) there is
really
> no point to "spam" server with unnecessary getData(...) calls.