[jira] [Commented] (HBASE-5790) ZKUtil deleteRecurisively should be a recoverable operation
[ https://issues.apache.org/jira/browse/HBASE-5790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253956#comment-13253956 ] Jesse Yates commented on HBASE-5790: patch coming momentarily. ZKUtil deleteRecurisively should be a recoverable operation --- Key: HBASE-5790 URL: https://issues.apache.org/jira/browse/HBASE-5790 Project: HBase Issue Type: Improvement Reporter: Jesse Yates Assignee: Jesse Yates Labels: zookeeper Fix For: 0.96.0, 0.94.1 As of 3.4.3 Zookeeper now has full, multi-operation transaction. This means we can wholesale delete chunks of the zk tree and ensure that we don't have any pesky recursive delete issues where we delete the children of a node, but then a child joins before deletion of the parent. Even without transactions, this should be the behavior, but it is possible to make it much cleaner now that we have this new feature in zk. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5790) ZKUtil deleteRecurisively should be a recoverable operation
[ https://issues.apache.org/jira/browse/HBASE-5790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253984#comment-13253984 ] Zhihong Yu commented on HBASE-5790: --- {code} + * Recursively delete the path all children on that path. {code} 'the path all' - 'all the'. {code} + retryOrThrow(retryCounter, e, delete); {code} delete should be deleteRecursively. {code} + private void addAllChildrenToDeleteTransaction(Transaction trans, String path, int version) {code} I don't see how version is used to filter child nodes in the above method. ZKUtil deleteRecurisively should be a recoverable operation --- Key: HBASE-5790 URL: https://issues.apache.org/jira/browse/HBASE-5790 Project: HBase Issue Type: Improvement Reporter: Jesse Yates Assignee: Jesse Yates Labels: zookeeper Fix For: 0.96.0, 0.94.1 Attachments: java_HBASE-5790.patch As of 3.4.3 Zookeeper now has full, multi-operation transaction. This means we can wholesale delete chunks of the zk tree and ensure that we don't have any pesky recursive delete issues where we delete the children of a node, but then a child joins before deletion of the parent. Even without transactions, this should be the behavior, but it is possible to make it much cleaner now that we have this new feature in zk. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5790) ZKUtil deleteRecurisively should be a recoverable operation
[ https://issues.apache.org/jira/browse/HBASE-5790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253986#comment-13253986 ] Lars Hofhansl commented on HBASE-5790: -- Patch looks good. Will there be any request size problem if the subtree to delete is large? Super minor nit: Should point out in Javadoc that deleteRecursively and an idempotent operation. ZKUtil deleteRecurisively should be a recoverable operation --- Key: HBASE-5790 URL: https://issues.apache.org/jira/browse/HBASE-5790 Project: HBase Issue Type: Improvement Reporter: Jesse Yates Assignee: Jesse Yates Labels: zookeeper Fix For: 0.96.0, 0.94.1 Attachments: java_HBASE-5790.patch As of 3.4.3 Zookeeper now has full, multi-operation transaction. This means we can wholesale delete chunks of the zk tree and ensure that we don't have any pesky recursive delete issues where we delete the children of a node, but then a child joins before deletion of the parent. Even without transactions, this should be the behavior, but it is possible to make it much cleaner now that we have this new feature in zk. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-5790) ZKUtil deleteRecurisively should be a recoverable operation
[ https://issues.apache.org/jira/browse/HBASE-5790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13253997#comment-13253997 ] Jesse Yates commented on HBASE-5790: bq. I don't see how version is used to filter child nodes in the above method. It works because of the line: {code} trans.delete(path, version); {code} in addAllChildrenToDeleteTransaction - only children with the same version will be deleted. Generally, we are just going to want to delete all versions (version == -1), so don't often expect funky cases, but this way also ensures that you just delete children with the same version as the parent (and fail if those versions don't match up). I didn't want to go with any assumptions on versions of children vs. parent since there was not need for it yet AFAIK. bq. Will there be any request size problem if the subtree to delete is large? Not unless you are going to blow out the stack or memory. However, that seems incredibly unlikely. Seems a little excessive at this point to do the tail recursion optimization, but can switch to that if it seems a big issue. ZKUtil deleteRecurisively should be a recoverable operation --- Key: HBASE-5790 URL: https://issues.apache.org/jira/browse/HBASE-5790 Project: HBase Issue Type: Improvement Reporter: Jesse Yates Assignee: Jesse Yates Labels: zookeeper Fix For: 0.96.0, 0.94.1 Attachments: java_HBASE-5790.patch As of 3.4.3 Zookeeper now has full, multi-operation transaction. This means we can wholesale delete chunks of the zk tree and ensure that we don't have any pesky recursive delete issues where we delete the children of a node, but then a child joins before deletion of the parent. Even without transactions, this should be the behavior, but it is possible to make it much cleaner now that we have this new feature in zk. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira