[
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 <name>hbase.zookeeper.useMulti</name>
10 <value>false</value>
9 <description>Instructs 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
