[
https://issues.apache.org/jira/browse/ZOOKEEPER-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850359#action_12850359
]
Henry Robinson commented on ZOOKEEPER-729:
------------------------------------------
Thanks for the patch, Kay!
I have a couple of review comments:
1. You should get rid of the System.out.println lines - use LOG if you want to
save something.
2. It might be cleaner to use a LinkedList of nodes, always prepending to the
front, then you can walk through it in order, but I don't mind which you do.
3. If delete fails due to a NoNode exception or similar, this operation aborts
I think. I'm not sure whether that's a good idea or not, but it should be
documented in the comments.
Something I wanted to flag up - this algorithm is not wait-free because if
another process is continually adding child nodes in the right place, this will
never finish. It is, however, obstruction-free. ISTR that ZooKeeper's
wait-freedom was a significant feature in one of Flavio's presentations that I
read. Are we ok relaxing this restriction for the client libraries for an
unlikely edge case?
(My vote is yes, we probably are, but this is not just an academic distinction
- you can build systems predicated on wait-freedom that will fail if they are
actually just obstruction-free).
> zkCli.sh -rmr /node
> -------------------
>
> Key: ZOOKEEPER-729
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-729
> Project: Zookeeper
> Issue Type: New Feature
> Components: c client, java client
> Reporter: Kay Kay
> Assignee: Kay Kay
> Fix For: 3.4.0
>
> Attachments: ZOOKEEPER-729.patch
>
>
> Recursively delete a given znode in zookeeper, from the command-line.
> New operation "rmr" added to zkclient.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
