The watches are just a signal that something on the node that you were
watching has changed. It does not get you the diff back saying what changed.
So you will have to read/stat the node in order for you to check what
The way the watches are implemented in Zookeeper is such that it keeps the
state management on a server (per client) low. This helps us keeping the
watches as lightweight operations on the servers.
We had been looking at providing a stream of updates for a node which a
client could subscribe to, but that is not on our roadmap right now.
I hope this helps.
On 1/3/09 8:05 PM, "Kevin Burton" <bur...@spinn3r.com> wrote:
>> Because watches are one time triggers and there is latency between getting
>> event and sending a new request to get a watch you cannot reliably see
>> change that happens to a node in ZooKeeper. Be prepared to handle the case
>> the znode changes multiple times between getting the event and setting the
>> again. (You may not care, but at least realize it may happen.)
> This seems the opposite of what would be desirable in an ideal client.
> So if I'm only using watches, and a file is changed with values 1,2,3,4
> rapidly, I may lose and never see value 4? Or I'll just not see 2,3?
> In one situation I'm worried about have a distributed process I'm trying to
> start, stop. I wouldn't want them to drop the second stop.
> How hard would it be to have every mutate event (delete, write, acl change,
> etc) be an event which is persistent and the client sees every change?