PathChildrenCache was never intended to retain the order of events. In my 
opinion, relying on order of events in a ZooKeeper-based application is a 
design mistake. PathChildrenCache is designed to provide an eventually 
consistent view of a ZNode’s children.

Imesha, can you explain why you need to rely on event ordering?

-Jordan

> On Oct 24, 2016, at 11:20 AM, Scott Blum <[email protected]> wrote:
> 
> Are you sure?  I haven't dug deeply into PathChildrenCache but TreeCache 
> definitely does not work this way.  The act of re-registering the watcher is 
> what fetches data.  Let me amend your event list:
> 
> -Watch children of /X
> -Node /X/1 added
> -TreeCache receives the ZK event for /X children changed
> -Node /X/2 added (this event would be missed).
> -TreeCache calls getChildren(/X) to re-register the watcher, sees both /X/1 
> and /X/2
> -TreeCache publishes events for both /X/1 and /X/2
> 
> I looked at PathChildrenCache just a little and it looks like it might work 
> the same way.
> 
> 
> IIRC, the kinds of events that might be missed are this:
> 
> -Watch children of /X
> -Node /X/1 added
> -TreeCache receives the ZK event for /X children changed
> -Node /X/2 added (this event would be missed).
> -Node /X/2 deleted (this event would be missed).
> -TreeCache calls getChildren(/X) to re-register the watcher, sees only /X/1
> 
> In this case, TreeCache would never know about the existence of /X/2 since it 
> was created and deleted without the client being able to "see" it.  This is a 
> limitation in ZK's design.
> 
> On Sun, Oct 23, 2016 at 10:44 PM, Cameron McKenzie <[email protected] 
> <mailto:[email protected]>> wrote:
> Ordering should be consistent. There is always the possibility of missing a 
> CHILD_CREATED event (or any other event), if it occurs in between the ZK 
> client being notified of an event and before the client has reregistered the 
> watch.
> 
> i.e.
> 
> -Watch children of /X
> -Node /X/1 added
> -Client is notified of /X/1 child created event
> -Node /X/2 added (this event would be missed).
> -Client reregisters watch for children on /X
> 
> 
> On Mon, Oct 24, 2016 at 1:15 PM, Imesha Sudasingha <[email protected] 
> <mailto:[email protected]>> wrote:
> Thank you for the response.
> 
> Yes, I'm aware of the conditions of an eventually consistent system. What I 
> wanted to know was, is there any possibility for the PathChildrenCache to 
> emit CHILD_CREATED like events out of order and what is the possibility of 
> missing such event?
> 
> Regards, 
> Imesha Sudasingha
> 
> 
> On Oct 21, 2016 7:12 PM, "Jordan Zimmerman" <[email protected] 
> <mailto:[email protected]>> wrote:
>> PathChildrenCache[1] is the solution you have provided to watch on a given 
>> node without using native zookeeper watchers.
> 
> PathChildrenCache uses native watchers. Have a look at the source. 
> 
>> Can anyone please clarify how the above effect can affect the accuracy of 
>> events listened?
> 
> The point of that message is to remind you that ZooKeeper is an eventually 
> consistent system. You are always seeing the view that the server you are 
> connected to has. This is a feature of ZooKeeper, not Curator.
> 
> Hope this helps.
> 
> -Jordan
> 
>> On Oct 21, 2016, at 4:44 AM, Imesha Sudasingha <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>> Hi all,
>> 
>> I have been using apache zookeeper. Now I'm willing to switch to 
>> CuratorFramework as it contains many useful recipes inbuilt. 
>> 
>> PathChildrenCache[1] is the solution you have provided to watch on a given 
>> node without using native zookeeper watchers. As I went through the API [1] 
>> documentation, the following ambiguous sentence has caused me to think twice 
>> as I want consistency accuracy for my implementation (such as not missing 
>> CHILD_CREATED events).
>> 
>> "it's not possible to stay transactionally in sync. Users of this class must 
>> be prepared for false-positives and false-negatives. Additionally, always 
>> use the version number when updating data to avoid overwriting another 
>> process' change."
>> 
>> Can anyone please clarify how the above effect can affect the accuracy of 
>> events listened? And is there a way to w atch on a given node without using 
>> Zookeeper watchers and PathChildrenCache?
>> 
>> (PathChildrenCache has the functionality I required. But the above 
>> description in the API docs matters me)
>> 
>> Thanks in advance!
>> 
>> [1] 
>> https://curator.apache.org/apidocs/org/apache/curator/framework/recipes/cache/PathChildrenCache.html
>>  
>> <https://curator.apache.org/apidocs/org/apache/curator/framework/recipes/cache/PathChildrenCache.html>
>> 
>> Regards,
>> Imesha Sudasingha
>> 
>> -- 
>> Imesha Sudasingha
>> Undergraduate of Department of Computer Science and  Engineering,
>> University of Moratuwa.
>> +94717086160 <tel:%2B94717086160>
>> View in Linkedin <https://lk.linkedin.com/in/imeshasudasingha>
> 
> 

Reply via email to