Hello, Does anyone have any thoughts on this?
Thanks, Patrick On Tue, Jun 17, 2014 at 1:06 PM, Patrick Peralta <[email protected]> wrote: > Hello, > > Apologies if this has been previously discussed (I could not find a good > search interface for the list archives). The methods of starting up > PathChildrenCache are as follows: > > /** > * Method of priming cache on {@link > PathChildrenCache#start(StartMode)} > */ > public enum StartMode > { > /** > * cache will _not_ be primed. i.e. it will start empty and you > will receive > * events for all nodes added, etc. > */ > NORMAL, > > /** > * {@link PathChildrenCache#rebuild()} will be called before this > method returns in > * order to get an initial view of the node. > */ > BUILD_INITIAL_CACHE, > > /** > * After cache is primed with initial values (in the background) a > * {@link PathChildrenCacheEvent.Type#INITIALIZED} will be posted > */ > POST_INITIALIZED_EVENT > } > > However, the start method does the following: > > case NORMAL: > { > offerOperation(new RefreshOperation(this, > RefreshMode.STANDARD)); > break; > } > > It seems to be that the behavior is the same as POST_INITIALIZED_EVENT, > except that an event isn't posted when the cache has been populated. I was > surprised to see my listeners receiving events even though the cache was > supposed to be empty on startup. > > I don't actually have a requirement to start with an empty cache; I was > just mostly confused about the difference between the doc and the actual > behavior. Perhaps the doc should be updated to reflect the existing > behavior, assuming that it is intentional? > > Thanks! > Patrick >
