hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Duo Zhang (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-16835) Revisit the zookeeper usage at client side
Date Fri, 14 Oct 2016 05:31:20 GMT

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

Duo Zhang commented on HBASE-16835:

Why do we need curator here rather than our own zk stuff?

Duo Zhang
As said above, if we decide to use watcher then the curator-recipes is very useful. And if
we fetch data from zk every time, then our RecoverableZooKeeper does not support async operations.
I could add the support for it but I think our zk stuff is too heavy to be used at client
side, most logic is unnecessary for a client implementation as we do not store any data on
zk at client, only read. And we need to be careful when modify the zk stuff as it will also
be used at server side which is much more critical. The recovery and retry provided by curator
is enough to be used at client side.

Michael Stack
Suggest you throw this paragraph and above zk back and forth into the new zk discussion issue.
Its good stuff.

So Curator has an async API? If so, it is an acceptable justification to bring in that dependency.

> Revisit the zookeeper usage at client side
> ------------------------------------------
>                 Key: HBASE-16835
>                 URL: https://issues.apache.org/jira/browse/HBASE-16835
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Duo Zhang
> Watcher or not.
> Curator or not.
> Keep connection or not.
> ...

This message was sent by Atlassian JIRA

View raw message