[
https://issues.apache.org/jira/browse/HBASE-9864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13964311#comment-13964311
]
Matteo Bertozzi commented on HBASE-9864:
----------------------------------------
{quote}
Yes, the grant or revoke, or label definition, or setauths, etc. should be
retried since it failed to be consistently applied.
(In addition, as part of cleanup any cache updates applied should be rolled
back.)
{quote}
ok, we were trying to unify all the cache updates under a single mechanism but
I guess is fine having a relaxed update and a non-relaxed one for security like
features. In this case we can just use the Procedure that we have today for the
non-relaxed notification, but this means to change operations as something like
this:
* RPC revoke
** new Procedure(revoke)
** acquire: fetch new updates
** reached: Add the revoke to table + apply the updates
** abort: discard the updates
> 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
> Priority: Blocker
> Fix For: 1.0.0
>
>
> 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.2#6252)
