curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ray Jenkins <...@librato.com>
Subject Re: NodeCache, NodeCacheListeners and state.
Date Thu, 19 Feb 2015 23:23:40 GMT
Thanks Jordan,

One more quick question. Looking at the NodeCache code I was curious if
there is a possibility that a NodeCache could become stale if a write
occurs on another client while a NodeCache is in the process of
initialization via a start(true). It looks like NodeCache checks to see if
it should initialize before calling reset()

if ( buildInitial ) {
   internalRebuild();
}

reset();

internalRebuild does not issue a read with a watch, so if a write were to
occur, say from another client before that watch is set in reset(), is it
possible NodeCache will be stuck with stale state until a future subsequent
write to the same znode?

Thanks
-R

On Thu, Feb 19, 2015 at 2:06 PM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:

> can I assume that this data is at least as current as the last write
> committed on the node where this watch is triggered
>
> Yes. Though, because watches are serialized, there may be additional
> changes downstream waiting to execute.
>
> Ultimately I am trying to understand if I can reason about the data that
> is being passed in the CuratorEvent to processBackgroundResult.
>
> The important thing to understand is that you are getting a view at a
> moment in time. ZooKeeper is not a transactional system therefore you you
> cannot assume that the current view is the most recent state.
>
>
> -JZ
>
>
>
> On February 19, 2015 at 1:42:13 AM, Ray Jenkins (ray@librato.com) wrote:
>
> Hi All,
>
> I have a question about NodeCache's and NodeCacheListeners. I have read
> the documentation that states,
>
> *"it's not possible to stay transactionally in sync. Users of this class
> must be prepared for false-positives and false-negatives. "*
>
> It makes sense to me that if I query the NodeCache via a getCurrentData()
> call the cache may not be up to date with the leader, but I'm trying to
> understand how this pertains to the use of notifications via a
> NodeCacheListener.
>
> Are there any guarantees that can be made about the state of the NodeCache
> when a NodeCacheListener is notified, for example, considering the
> following code.
>   this.nodeCacheListener = new NodeCacheListener() {
>   @Override
>   public void nodeChanged() throws Exception {
>     nodeCache.getCurrentData().getData()
>   }
> }
>
> this.nodeCache.getListenable().addListener(nodeCacheListener);
> this.nodeCache.start(true);
>
> When nodeChanged() is called and I examine the contents of nodeCache in
> the callback, can I assume that this data is at least as current as the
> last write committed on the node where this watch is triggered or is it
> possible that the nodeCache contains an even earlier view of this znode's
> data?
>
> From looking at the code it appears curator issues a read call after the
> watch is triggered and passes that result in a CuratorEvent to
> processBackgroundResult, setNewData is then called on the cache updating
> the contents of the AtomicReference and if a Objects.equals comparison
> fails the listeners are notified.
>
> Ultimately I am trying to understand if I can reason about the data that
> is being passed in the CuratorEvent to processBackgroundResult. If that
> data is the result of a read request issued to any node in the cluster, it
> is possible that the result was issued by a node that was not part of the
> quorum that accepted the write that triggered the watch, therefore the
> local node could be in sync with the leader but the cache could still be
> out of sync? Or is that read indicative of the local state of the node
> after a write has been committed?
>
> I don't see sync() called anywhere in the curator code when issuing a
> read, but is there any way to reason about the state of the NodeCache
> contents after a nodeChanged call, besides the fact that it may be stale?
>
> Thanks,
> -Ray
>
>

Mime
View raw message