[
https://issues.apache.org/jira/browse/HBASE-7411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13551540#comment-13551540
]
Andrew Purtell edited comment on HBASE-7411 at 1/11/13 9:40 PM:
----------------------------------------------------------------
I don't think depending on a third party single owner library for something so
critical is a good idea. What assurances can be provided that when we trace a
difficult to debug problem in prod to Curator we can get a contributed fix in a
new Curator release in a timely manner? In the interim, won't we then be
forking Curator with a custom patch and hosting a curator-x.y-HBASE Maven
artifact somewhere, just like we did with Junit/Surefire, which by the way is
much more widely used (and likely to have community bandwidth).
Importing proven code that we ourselves could change is no problem, otherwise
I'd have to consider a veto.
Edit: Make argument more intelligible, please pardon.
was (Author: apurtell):
I don't think depending on a third party single owner library for something
so critical is a good idea. What assurances can be provided that when we trace
a difficult to debug problem in prod to Curator we can get a contributed fix in
a new Curator release in a timely manner? Won't we then be forking Curator with
a custom patch and hosting a curator-x.y-HBASE Maven artifact somewhere, just
like we did with Junit/Surefire, which by the way is much more widely used (and
likely to have community bandwidth).
Importing proven code that we ourselves could change is no problem, otherwise
I'd have to consider a veto.
> 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
> Attachments: hbase-7411_v0.patch
>
>
> 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
