Persistent watches........

[Kevin Burton <bu...@spinn3r.com>]

> 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

-- 
Founder/CEO Spinn3r.com
Location: San Francisco, CA
AIM/YIM: sfburtonator
Skype: burtonator
Work: http://spinn3r.com

Re: Persistent watches........

[Mahadev Konar <ma...@yahoo-inc.com>]

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" <bu...@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