hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-9864) Notifications bus for use by cluster members keeping up-to-date on changes
Date Wed, 09 Apr 2014 03:57:36 GMT

    [ https://issues.apache.org/jira/browse/HBASE-9864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13963767#comment-13963767
] 

stack commented on HBASE-9864:
------------------------------

bq. I'm a lot more concerned about a "revoke user" that doesn't get applied for hours because
someone was napping.

What you thinking Andrew?  Chatting w/ Matteo, if a RS fails to update its local cache, it
should abort as we would not being able to update our WAL.  No napping allowed.

You need something in the 0.98 timeframe too boss?

bq. 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?

There are others to undo our zk heavy-reliance, yes.  The suggestion here is that in genericizing
a notification system, if possible, avoid zk if we can (Yeah, current zk 'works' but if we
could avoid having to go to another system...).

> 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)

Mime
View raw message