curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ray Jenkins <...@librato.com>
Subject NodeCache, NodeCacheListeners and state.
Date Thu, 19 Feb 2015 06:40:15 GMT
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