HI Kevin, 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 changed.
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. Thanks mahadev 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 > the >> event and sending a new request to get a watch you cannot reliably see > every >> change that happens to a node in ZooKeeper. Be prepared to handle the case > where >> the znode changes multiple times between getting the event and setting the > watch >> 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? > > Kevin
