[
https://issues.apache.org/jira/browse/CURATOR-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14082697#comment-14082697
]
ASF GitHub Bot commented on CURATOR-33:
---------------------------------------
Github user dragonsinth commented on the pull request:
https://github.com/apache/curator/pull/17#issuecomment-50919247
Yes, and I think that's okay. refreshData() should be concurrency safe.
All it does is atomically increment the outstanding ops (so no race there),
then queue up a curator background operation, e.g.
`client.getData().usingWatcher(this).inBackground(this).forPath(path);`
There's no reason this would be a problem, right? path is final so it
won't change, CuratorFramework itself should be thread safe, and if the same
operation happens twice at the same time, the callbacks will still come back in
serial, and the second (duplicate) result should be the same and not produce an
event.
> Recursive Node Cache
> --------------------
>
> Key: CURATOR-33
> URL: https://issues.apache.org/jira/browse/CURATOR-33
> Project: Apache Curator
> Issue Type: Improvement
> Components: Recipes
> Reporter: John Vines
> Assignee: Jordan Zimmerman
> Fix For: TBD
>
> Attachments: CURATOR-33.2.patch, CURATOR-33.patch
>
>
> Currently the PathChildrenCache will trigger listen events for all children
> at the given node. However, it would be useful to have a cache that would
> trigger listen events for the entire hierarchy below the given node.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
