curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: PathChildrenCache start behavior
Date Mon, 23 Jun 2014 15:52:01 GMT
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 pperalta@gopivotal.com
Reply: user@curator.apache.org user@curator.apache.org
Date: June 23, 2014 at 8:25:55 AM
To: user@curator.apache.org user@curator.apache.org
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 <pperalta@gopivotal.com> 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


Mime
View raw message