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