[
https://issues.apache.org/jira/browse/HBASE-9864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13961659#comment-13961659
]
Mikhail Antonov commented on HBASE-9864:
----------------------------------------
[~apurtell]
when you're talking about "propagated in the background with best effort" and
"internal distributed non-persistent store", and that it doesn't have to be
coupled to ZK, you mean that this store would be kind of option for the
consensus library (referred via HBASE-10909), and that it would have 2 modes of
replication - one for "guaranteed" propagation of distributed state (like part
of distributed state machine" and one for "best effort" propagation"? Do I
understand that correct? I.e. when you say "best effort", what kind of
guarantees you imply?
> 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)