hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-9507) Promote methods of WALActionsListener to WALObserver
Date Tue, 20 May 2014 01:25:38 GMT

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

Enis Soztutar commented on HBASE-9507:

bq. Closing this as superseded by the more thorough evaluation happening over on HBASE-10504.
I think HBASE-10504 defines the replication interface, but async to the write path. On the
other hand WALObserver is sync to the write path. So if you want to do phoenix-style secondary
indexes, you would need sync-style interfaces, no? 

> Promote methods of WALActionsListener to WALObserver
> ----------------------------------------------------
>                 Key: HBASE-9507
>                 URL: https://issues.apache.org/jira/browse/HBASE-9507
>             Project: HBase
>          Issue Type: Brainstorming
>          Components: Coprocessors, wal
>            Reporter: Nick Dimiduk
>            Priority: Minor
>             Fix For: 0.99.0
> The interface exposed by WALObserver is quite minimal. To implement anything of significance
based on WAL events, WALActionsListener (at a minimum) is required. This is demonstrated by
the implementation of the replication feature (not currently possible with coprocessors) and
the corresponding interface exploitation that is the [Side-Effect Processor|https://github.com/NGDATA/hbase-indexer/tree/master/hbase-sep].
Consider promoting the interface of WALActionsListener into WALObserver. This goes a long
way to being able refactor replication into a coprocessor. This also removes the duplicate
code path for listeners because they're already available via coprocessor hook.

This message was sent by Atlassian JIRA

View raw message