[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12850375#action_12850375
 ] 

Kay Kay commented on ZOOKEEPER-729:
-----------------------------------

{quote}
It would be great if you could include this change in the c client as well. 
Would you mind updating
the patch for that as well?
{quote}

Would it be ok if we have a separate jira to track it. I can update the same, 
but the motivation for me was , when we reset a katta cluster , I wanted to 
have a single command to deal with resets.  For consistency purposes, I can 
have a look at the C client as well. 


{quote}
You added a new "rmr" command, rather could you just add a "-r" option to the 
delete command (see create for
similar command line options on a command)
{quote}

makes sense. that was an inspiration from hdfs, to avoid keystrokes, as you 
might have figured out already ;) 

{quote}
I see that you are using sync operations, did you consider using async? It 
would be much faster and would be a
great example for users {quote}

I wanted to delete the nodes in order, the leaves and then the root, and was 
not sure what effect async will have , in that, w.r.t race conditions. Also I 
was testing from the cmd line and wanted to be sure that when the command 
returns, every child node has indeed been deleted. 

Can you add some more hints ? 

{quote}
1. You should get rid of the System.out.println lines - use LOG if you want to 
save something. 
{quote}
Oops. Saw, System.err elsewhere in ZookeeperMain and confused that to be the 
standard with Zookeeper . 

{quote}
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.
{quote}

I guess, aborting is ok, so we know what is happening. May be - there could be 
another parameter to indicate if we are continuing / aborting. 

{quote}
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.
{quote} 

This is true. As I had mentioned  in the assumptions - this is mostly to be 
used as a 1-step reset for apps, and the client apps are assumed to have been 
brought down completely. 
May be- for now - indicating the information in the comments would do ? 



> 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