[jira] [Updated] (HBASE-5790) ZKUtil deleteRecursively should be a recoverable operation
[ https://issues.apache.org/jira/browse/HBASE-5790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Yates updated HBASE-5790: --- Assignee: (was: Jesse Yates) > ZKUtil deleteRecursively 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 > Labels: zookeeper > Attachments: java_HBASE-5790-v1.patch, 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 was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-5790) ZKUtil deleteRecursively should be a recoverable operation
[ https://issues.apache.org/jira/browse/HBASE-5790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-5790: -- Status: Open (was: Patch Available) Cancelling stale patch. We're up to minimum necessary ZK now I'd say. Revisit? Or close. ZKUtil deleteRecursively 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 Attachments: java_HBASE-5790-v1.patch, 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 was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-5790) ZKUtil deleteRecursively should be a recoverable operation
[
https://issues.apache.org/jira/browse/HBASE-5790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-5790:
-
Fix Version/s: (was: 0.95.0)
Removing improvement that depends on 3.4zk.
Our Greg added a flag where you can set it if the quorum is 3.4.
{code}
12 property
11 namehbase.zookeeper.useMulti/name
10 valuefalse/value
9 descriptionInstructs HBase to make use of ZooKeeper's multi-update
functionality.
8 This allows certain ZooKeeper operations to complete more quickly and
prevents some issues
7 with rare Replication failure scenarios (see the release note of
HBASE-2611 for an example).
6 IMPORTANT: only set this to true if all ZooKeeper servers in the
cluster are on version 3.4+
5 and will not be downgraded. ZooKeeper versions before 3.4 do not
support multi-update and will
4 not fail gracefully if multi-update is invoked (see ZOOKEEPER-1495).
3 /description
2 /property
{code}
If patch was refactored to use this config., I'd commit.
ZKUtil deleteRecursively 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
Attachments: java_HBASE-5790.patch, java_HBASE-5790-v1.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
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HBASE-5790) ZKUtil deleteRecursively should be a recoverable operation
[ https://issues.apache.org/jira/browse/HBASE-5790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated HBASE-5790: - Fix Version/s: (was: 0.94.1) Release Note: Unscheduling from 0.94.x, because ZK 3.4.x requirement. ZKUtil deleteRecursively 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 Attachments: java_HBASE-5790-v1.patch, 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] [Updated] (HBASE-5790) ZKUtil deleteRecursively should be a recoverable operation
[ https://issues.apache.org/jira/browse/HBASE-5790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhihong Yu updated HBASE-5790: -- Hadoop Flags: Reviewed Status: Patch Available (was: Open) ZKUtil deleteRecursively 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-v1.patch, 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] [Updated] (HBASE-5790) ZKUtil deleteRecursively should be a recoverable operation
[ https://issues.apache.org/jira/browse/HBASE-5790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesse Yates updated HBASE-5790: --- Summary: ZKUtil deleteRecursively should be a recoverable operation (was: ZKUtil deleteRecurisively should be a recoverable operation) ZKUtil deleteRecursively 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-v1.patch, 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
