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