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-10504) Define Replication Interface
Date Fri, 16 May 2014 11:02:02 GMT

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

Enis Soztutar commented on HBASE-10504:

bq. This seems to me like work that is difficult to justify for the SEP because it makes use
of existing HBase RPC and replication failover handling, and currently works
Of course RPC and RS discovery etc are internal to HBase. The main advantage would be that
you will be protected against changes there. 
bq. Obviously these comments are purely from the standpoint of SEP maintenance. As I mentioned
in a previous comment, I think that this proposal would be a great addition to HBase and very
useful – I just don't see it's usefulness to the SEP yet.
Fair enough. HBase's own inner workings for inter-cluster replication is not changing with
this patch, so you should be able to have SEP as it is. I think I don't fully understand why
would you want to have a proxy layer as a separate service (other than isolation issues).

> Define Replication Interface
> ----------------------------
>                 Key: HBASE-10504
>                 URL: https://issues.apache.org/jira/browse/HBASE-10504
>             Project: HBase
>          Issue Type: Task
>            Reporter: stack
>            Assignee: stack
>            Priority: Blocker
>             Fix For: 0.99.0
>         Attachments: hbase-10504_wip1.patch
> HBase has replication.  Fellas have been hijacking the replication apis to do all kinds
of perverse stuff like indexing hbase content (hbase-indexer https://github.com/NGDATA/hbase-indexer)
and our [~toffer] just showed up w/ overrides that replicate via an alternate channel (over
a secure thrift channel between dcs over on HBASE-9360).  This issue is about surfacing these
APIs as public with guarantees to downstreamers similar to those we have on our public client-facing
APIs (and so we don't break them for downstreamers).
> Any input [~phunt] or [~gabriel.reid] or [~toffer]?
> Thanks.

This message was sent by Atlassian JIRA

View raw message