Well, that’s not what PathChildrenCache is for. You could start a NodeCache for the parent node I guess. Or use TreeCache. But, I don’t know what the use case is so I can’t comment in more detail.
-Jordan > On Oct 20, 2015, at 11:34 PM, Luo Fucong <[email protected]> wrote: > > Thanks for the reply. > > Sorry for the ambiguous meaning of “path node”. By saying “path node”, I mean > the common root node of the children. > > So PathChildrenCach does store the children nodes Stat, but it does not store > the root node's Stat. > > For instance, I have created a PathChildrenCach cache = new > PathChildrenCache(“/path/to/node”). > I can get the Stat of “/path/to/node/child1”, but I cannot get the Stat of > “/path/to/node” directly from the cache. > >> 在 2015年10月21日，下午12:18，Jordan Zimmerman <[email protected]> 写道： >> >> PathChildrenCache stores the node’s Stat object in the ChildData. So, all >> the data you want is there. >> >> -JZ >> >>> On Oct 20, 2015, at 11:13 PM, 罗傅聪 <[email protected]> wrote: >>> >>> Hi all: >>> >>> I recently went through the PathChildrenCache source code (in >>> curator-recipes-2.9.0) and found that it does not store the path node’s >>> “cversion”, which indicating the number of changes to the children of this >>> znode. (Correct me if I’m wrong.) >>> >>> I think the “cversion” is a very important version number which enable us >>> to verify that the PathChildrenCache is really catch up to the remote >>> zookeeper znodes. >>> >>> So I’m wondering that: >>> >>> 1. why the PathChildrenCache does not store “cversion”, or furthermore, why >>> it does not store the path node’s status? >>> >>> 2. are there other means I can use to verify that the PathChildrenCache is >>> not falling behind the remote znodes? >>> >>> Thanks! >> >
