[jira] [Commented] (HBASE-16835) Revisit the zookeeper usage at client side

["Duo Zhang (JIRA)" <ji...@apache.org>]

    [ 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.

{quote}
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 of.

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.
{quote}



> 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
(v6.3.4#6332)