Sorry… Yes, POST_INITIALIZED_EVENT is the same as NORMAL except you get the INITIALIZED event. You can see this in TestPathChildrenCache.testChildrenInitialized(). Please send a PR with doc updates if you think they can be improved.
-Jordan From: Patrick Peralta [email protected] Reply: [email protected] [email protected] Date: June 23, 2014 at 8:25:55 AM To: [email protected] [email protected] Subject: Re: PathChildrenCache start behavior 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
