hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-7411) Use Netflix's Curator zookeeper library
Date Fri, 28 Jun 2013 20:55:21 GMT

    [ https://issues.apache.org/jira/browse/HBASE-7411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13695779#comment-13695779
] 

Enis Soztutar commented on HBASE-7411:
--------------------------------------

I've checked it again in Curator. The idempotency guard is there in create() which puts a
unique uuid as a prefix of the znode in CreateBuilderImpl (called setProtected()). But, I
also could not find the same protected guard in setData() as we do in RecoverableZookeeper.


As per our offline discussion, let's not pursue the approach in the patch for using curator
only for recipes, but keep the issue open for discussing completely migrating to curator after
0.96 comes out. We can raise the idempotency issue in curator and address it as a prerequisite.
 
                
> 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.95.2
>            Reporter: Enis Soztutar
>            Assignee: Enis Soztutar
>             Fix For: 0.95.2
>
>         Attachments: 7411v2.txt, 7411v2.txt, 7411v3.txt, 7411v4.txt, 7411v4.txt, 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

Mime
View raw message