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 Tue, 08 Apr 2014 20:36:16 GMT

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

stack commented on HBASE-9864:

The editor will not need to poke the master or the master will not need to do proactive scans
looking for updates if the argument that master and meta are tied prevails over in HBASE-10569.

So, allowing HBASE-10569, system table edits will be noticed 'immediately'.

In the proposal, we could pass the edit on the back of the heartbeat or easier, just prompt
the heartbeater go do the lookup on the table itself.  In the first case, it may be a full
heartbeat period before changes are noticed.  In the second case, it would be the heartbeat
period + time to scan the table.  This could be seconds.   Is this 'soon-as-possible' too
much for say, an ACL update?

On plus side, this is easy-to-do and undoes our reliance on a 3rd system (zk) for notification.

Later we could do a new Procedure mechanism if needed that writes over a new x-cluster direct
channel between Master and RS pushing out the change, waiting on all to acknowledge and taking
evasive action if any fails.  This would be more work but probably closer to 'immediate'.

> 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

View raw message