curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CURATOR-33) Recursive Node Cache
Date Fri, 01 Aug 2014 18:35:40 GMT

    [ 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)

Mime
View raw message