[
https://issues.apache.org/jira/browse/HBASE-9864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13810307#comment-13810307
]
Andrew Purtell commented on HBASE-9864:
---------------------------------------
Granting or revoking table or CF permissions or clearauths/setauths or
add_label is just like a snapshot prepare or schema change action, something
that needs to be globally applied and Procedure provides a way to do that with
tracking of success or failure in that regard. That seems like a good thing to
me. What we don't have with ZK watches today is any guarantee or confirmation
that all clients with a watch received notification. In practice it works but
ZK makes no guarantee, any given quorum peer can be behind the leader by some
delta. The guarantee that ZK provides is that any znode change that a client
sees was agreed upon by the majority at the time the proposal was committed.
The client can call sync() on a znode to ask the quorum peer to sync with the
leader first but to my knowledge there is no syncWatchers().
> Notifications bus for use by cluster members keeping up-to-date on changes
> --------------------------------------------------------------------------
>
> Key: HBASE-9864
> URL: https://issues.apache.org/jira/browse/HBASE-9864
> Project: HBase
> Issue Type: Brainstorming
> Reporter: stack
>
> In namespaces and acls, zk callbacks are used so all participating servers
> are notified when there is a change in acls/namespaces list.
> The new visibility tags feature coming in copies the same model of using zk
> with listeners for the features' particular notifications.
> Three systems each w/ their own implementation of the notifications all using
> zk w/ their own feature-specific watchers.
> Should probably unify.
> Do we have to go via zk? Seems like all want to be notified when an hbase
> table is updated. Could we tell servers directly rather than go via zk?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
