curator-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jordan Zimmerman <jor...@jordanzimmerman.com>
Subject Re: NodeCache, NodeCacheListeners and state.
Date Thu, 19 Feb 2015 20:06:17 GMT
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