if you do a getData("/a", true) and then "/a" changes, you will get a watch
event. if "/a" changes again, you will not get an event. so, if you want to
monitor "/a", you need to do a new getData() after each watch event to
reregister the watch and get the new value. (re-registering watches on
reconnect is a different issue. there are no disconnects in this example.)
you are correct that zookeeper has some subtle things to watch out for. that is
why we do not want to add more.
ben
-----Original Message-----
From: burtona...@gmail.com [mailto:burtona...@gmail.com] On Behalf Of Kevin
Burton
Sent: Thursday, January 08, 2009 11:58 AM
To: zookeeper-user@hadoop.apache.org
Subject: Re: Sending data during NodeDataChanged or NodeCreated
>
>
> while the case in which a value only changes once, can be made slightly
> more optimal by passing the value in the watch event. it is not worth the
> risk. in our experience we had a application that was able to make that
> assumption initially and then later when the assumption became invalid it
> was very hard to diagnose.
>
I don't quite follow. In this scenario you would be sent two events, with
two pieces of data.
If ZK re-registers watches on reconnect, I don't see how it could be easier
than this.
> we don't want to make zookeeper harder to use by introducing mechanisms
> that only work with subtle assumptions.
>
I definitely think ZK has too much rope right now. It's far too easy to
make mistakes and there are lots of subtle undocumented behaviors.
Kevin
--
Founder/CEO Spinn3r.com
Location: San Francisco, CA
AIM/YIM: sfburtonator
Skype: burtonator
Work: http://spinn3r.com
