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