curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McKenzie <mckenzie....@gmail.com>
Subject Re: Watcher latency question
Date Mon, 03 Nov 2014 05:11:25 GMT
hey Tony,
The way that watches work in ZK is that once they fire they need to be
added back again. If the data in ZK changes before the watch is reset, then
the client will not find out about this change in data.

i.e You're watching the data in node /test
-Data changes to state 'A'
-Watch fires
-Data changes to state 'B'
-Data changes to state 'A'
-Reset watch
-Data changes to state 'C'
-Watch fires

You're going to miss the intermediate state where the data transitioned
from state A to state B and back to state A again. This is just a
limitation of ZK, there's a window of opportunity for these events to be
missed. I don't think that the PathCache in Curator is going to solve this
problem.

Do you have a particular use case where missing these transitions is an
issue?

cheers
Cam

On Mon, Nov 3, 2014 at 4:04 PM, Tony Jackson <tjacksonfr@mail.com> wrote:

> I read some articles mentioning that Zookeeper watcher has latency issue.
> Something like before the next watcher is placed and after the previous
> watcher is triggered, it is possible that the client may not receive
> notification within that period.
>
>
> http://www.quora.com/Does-Zookeeper-clients-keep-open-lots-of-TCP-connections-if-so-how-scalable-is-it-Any-limits
>
> Then on the internet some people recommend using curator pathcache, which
> helps watch child znodes being added, updated, etc. operations. So my
> question - is it the right recipe to use if I want to avoid watcher latency
> problem? Otherwise which recipe should I use instead or how to avoid such
> problem with curator?
>
> http://curator.apache.org/curator-recipes/path-cache.html
>
> Thanks
>

Mime
View raw message