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

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

Reply via email to