[
https://issues.apache.org/jira/browse/HBASE-10504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13998525#comment-13998525
]
Gabriel Reid commented on HBASE-10504:
--------------------------------------
{quote}Even in that case, the server-client implementation will be much simpler
than what you have in SEP I think, which does hbase RPC + zookeeper + zk
mockup. Only a server discovery + simple one method thrift / PB RPC is what is
needed from my understanding. It would be great to have a skeleton for this
living in HBase proper as well.{quote}
The SEP does indeed make use of HBase RPC and ZK, and does masquerades in ZK as
a region server, but I don't see that much of an advantage of doing a separate
thrift or PB-based RPC. I think that this would just be exchanging one existing
RPC mechanism (hbase) for another (thrift/PB). The service discovery would
still be required, which would also involve ZK. Not having to do the setup of
masquerading as a regionserver would indeed be a plus.
Taking this road for the SEP would then require:
* defining/setting up RPC (which is currently already provided by hbase
* implementing a ReplicationConsumer (and deploying and configuring it in hbase
RS) that does service discovery, RPC endpoint selection, and properly deals
with failing/flaky RPC endpoints (also already provided in hbase replication)
* reworking the SEP RPC server to use the new RPC mechanism
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. I may very well be missing something, but I don't see how
reimplementing this stuff in the SEP would simplify things very much.
The one big potential advantage that I do see is that it would protect the SEP
from changes in the internal HBase replication interfaces.
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.
> 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
(v6.2#6252)
