[
https://issues.apache.org/jira/browse/HBASE-7411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13537580#comment-13537580
]
Enis Soztutar commented on HBASE-7411:
--------------------------------------
bq. Curator – HBase's use of ZooKeeper is absolutely critical. This should not
be outsourced, especially outside of an ASF Hadoop-ish project
Agreed that it is super critical that our zk usage is stable, debuggable, and
fixable. Again, the main reason for this issue is to reuse their recipes
(especially locks, and maybe queues, barriers and shared values). That is why I
am relying more on 3. If we find that the recipes are useful on their own, we
don't need to reimplement them, if not, we might as well just continue to
custom build our recipes.
> Use Netflix's Curator zookeeper library
> ---------------------------------------
>
> Key: HBASE-7411
> URL: https://issues.apache.org/jira/browse/HBASE-7411
> Project: HBase
> Issue Type: New Feature
> Components: Zookeeper
> Affects Versions: 0.96.0
> Reporter: Enis Soztutar
> Assignee: Enis Soztutar
>
> We have mentioned using the Curator library
> (https://github.com/Netflix/curator) elsewhere but we can continue the
> discussion in this.
> The advantages for the curator lib over ours are the recipes. We have very
> similar retrying mechanism, and we don't need much of the nice client-API
> layer.
> We also have similar Listener interface, etc.
> I think we can decide on one of the following options:
> 1. Do not depend on curator. We have some of the recipes, and some custom
> recipes (ZKAssign, Leader election, etc already working, locks in HBASE-5991,
> etc). We can also copy / fork some code from there.
> 2. Replace all of our zk usage / connection management to curator. We may
> keep the current set of API's as a thin wrapper.
> 3. Use our own connection management / retry logic, and build a custom
> CuratorFramework implementation for the curator recipes. This will keep the
> current zk logic/code intact, and allow us to use curator-recipes as we see
> fit.
> 4. Allow both curator and our zk layer to manage the connection. We will
> still have 1 connection, but 2 abstraction layers sharing it. This is the
> easiest to implement, but a freak show?
> I have a patch for 4, and now prototyping 2 or 3 whichever will be less
> painful.
> Related issues:
> HBASE-5547
> HBASE-7305
> HBASE-7212
--
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
