[
https://issues.apache.org/jira/browse/HBASE-9864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13963445#comment-13963445
]
Matteo Bertozzi commented on HBASE-9864:
----------------------------------------
{quote}I'm not concerned with time, it's the guarantee that the update has been
applied at every live location (or not){quote}
If a "cache update" cannot be applied, is probably because that RS is in a bad
state. and it should be aborted.
if it is just slow (e.g. GC) no one can probably query it, so in that case is
fine if the cache update it will be applied later.
I don't think the procedure is a good thing e.g. for ACL
let say that one node is in GC or has some network problem.
You try to do "grant user" and it fails because one node is not responding
within N seconds.
by using the "heartbeat" everyone will be updated as soon as they can
> 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)
