[
https://issues.apache.org/jira/browse/CURATOR-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15267115#comment-15267115
]
Tommy Becker edited comment on CURATOR-319 at 5/2/16 6:04 PM:
--------------------------------------------------------------
Yeah, I guess it's not entirely straightforward. But in my mind, something
labeled a cache should not modify ZK at all. Maybe there could be a mode where
an exception is thrown when the cache is started if the node that it's caching
isn't there. And then if it subsequently goes away, just returning null for the
contents.
was (Author: twbecker):
Yeah, I guess it's not entirely straightforward. I guess in my mind, something
labeled a cache should not modify ZK at all. Maybe there could be a mode where
an exception is thrown when the cache is started if the node that it's caching
isn't there. And then if it subsequently goes away, just returning null for the
contents.
> NodeCache recreates deleted parents of the node being cached
> ------------------------------------------------------------
>
> Key: CURATOR-319
> URL: https://issues.apache.org/jira/browse/CURATOR-319
> Project: Apache Curator
> Issue Type: Bug
> Components: Recipes
> Affects Versions: 2.10.0
> Reporter: Tommy Becker
>
> Starting with Curator 2.10.0, the NodeCache will spontaneously re-create
> parents of the node being cached if one of them is deleted. As an example,
> if there is a NodeCache watching node /a/b/c and node b is deleted, the cache
> will immediately recreate node b (but not c) when the change is processed.
> This seems to stem from this commit:
> https://github.com/apache/curator/commit/f02fb225d531506444b54cdf5effb0529a35cdb0
> This was not the behavior prior to 2.10.0, and seems pretty unexpected.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
