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?
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.
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)
makes sense. that was an inspiration from hdfs, to avoid keystrokes, as you might have figured out already
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
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 ?
1. You should get rid of the System.out.println lines - use LOG if you want to save something.
Oops. Saw, System.err elsewhere in ZookeeperMain and confused that to be the standard with Zookeeper .
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.
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.
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.
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 ?