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:30:21 GMT

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

Duo Zhang commented on HBASE-16835:

Paste the comments on rb here.

Michael Stack
In the past we avoided curator because our zk thingy -- RecoverableZookeeper -- was supposed
to be immune to the case where we'd miss an update. All data in zk was preceded by some version
number and if we did not get the version expected, then we'd know there'd be a change on us.

Not sure if curator does this now.

This is all stuff from long ago. I'm sure the world changed since but something to be aware

Duo Zhang
ZooKeeper could miss some update, this is by design. Not like etcd, zk does not give you all
the update events of a node. Instead, it just tell you that the data has been changed, you
need to fetch it from zk then. That's why the watcher can only be notified once. It means
when you receive a notification from watcher then you need to do a getAndWatch or existsAndWatch
to get the result and set a new watcher on it. It does not matter if the data is changed after
the watcher tells you it is changed, you will see the modified data when you actual get it.
And it does not matter if the data is changed after you get it, you set a watcher, the watcher
will tell you the that you need to get the new data.

I think this is enough for client usage. At the server side, yeah sometimes we need to get
a consistent view of a tree. Curator's PathChildrenCache is not suitable under this scenario.
The only way is to check the version number after fetching...

Duo Zhang
And I still need curator even if I do not use the recipes in it as our RecoverableZooKeeper
does not support callback. I could add the support for it but I think it is too heavy for
a client since we do not need to write anything to zookeeper from client...
And I think RS can not recover from a session expire error? But client should be able to reconnect
even after a session expire as we do not store any state on zk.

Michael Stack
ok. Argument for Curator on the client-side only seems fine, reasonable. How to ensure client-side
only usage. Do I/we need to do a review of zk usage (in another issue) to identify those cases
where we need to see all changes (This need may be going away w/ our using zk less often)

Duo Zhang
I think this is the duty of committers? We as committer should prevent the wrong usage introduced
by contributors in the future :)
And now I think the only place where we use curator is in the ZKClusterRegistry introduced
in this patch.

Michael Stack
I like your point above that client should be able to recover from a session expiration. We
don't do that currently IIRC. Open an issue so it gets attention. Good point.

> 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