Github user jhump commented on a diff in the pull request:
https://github.com/apache/curator/pull/42#discussion_r19055906
--- Diff:
curator-recipes/src/main/java/org/apache/curator/framework/recipes/cache/TreeCache.java
---
@@ -179,24 +191,34 @@ public static Builder newBuilder(CuratorFramework
client, String path)
final AtomicReference<Stat> stat = new AtomicReference<Stat>();
final AtomicReference<byte[]> data = new AtomicReference<byte[]>();
final AtomicReference<ConcurrentMap<String, TreeNode>> children =
new AtomicReference<ConcurrentMap<String, TreeNode>>();
+ final int depth;
TreeNode(String path, TreeNode parent)
{
this.path = path;
this.parent = parent;
+ this.depth = parent == null ? 0 : parent.depth + 1;
}
private void refresh() throws Exception
{
- outstandingOps.addAndGet(2);
- doRefreshData();
- doRefreshChildren();
+ if (depth < maxDepth)
--- End diff --
I know this wasn't the intent of this PR. But to *really* solve an even
larger class of problems, we can make this more flexible. What I'm thinking,
instead of hard-coded criteria by depth, is the ability to provide a
`Predicate` for filtering parts of the sub-tree that don't need to be cached.
Ideally, the predicate would be applied in a different spot than here. That
way we can filter individual nodes out of the cache. (This approach only lets
me say "yes, include all of this node's children" or "no, none of its
children".)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
