[
https://issues.apache.org/jira/browse/HBASE-9864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13963437#comment-13963437
]
Andrew Purtell commented on HBASE-9864:
---------------------------------------
bq. On plus side, this is easy-to-do and undoes our reliance on a 3rd system
(zk) for notification.
I thought other issues are undoing our reliance on ZK? Presumably distributed
barriers would be ported to it so therefore no reliance on ZK then?
bq. Later we could do a new Procedure mechanism
I think it needs to be now. We have anecdotal evidence that ZK watches "work"
but won't have such evidence for something else. We should not be comfortable
with security subsystems that need consistent state everywhere running on
something that doesn't guarantee that. Every current component that has a cache
like this needs this guarantee (ACLs, visibility, namespaces) right?
> 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)
