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.

Reply via email to