[jira] [Created] (HBASE-18846) Accommodate the hbase-indexer/lily/SEP consumer deploy-type

["stack (JIRA)" <ji...@apache.org>]

stack created HBASE-18846:
-----------------------------

             Summary: Accommodate the hbase-indexer/lily/SEP consumer deploy-type
                 Key: HBASE-18846
                 URL: https://issues.apache.org/jira/browse/HBASE-18846
             Project: HBase
          Issue Type: Bug
            Reporter: stack


This is a follow-on from HBASE-10504, Define a Replication Interface. There we defined a new, flexible replication endpoint for others to implement but it did little to help the case of the lily hbase-indexer. This issue takes up the case of the hbase-indexer.

The hbase-indexer poses to hbase as a 'fake' peer cluster. The hbase-indexer will start up cut-down "RegionServer" processes that are nought but an hbase RpcServer hosting an AdminProtos Service. They make themselves 'appear' to the Replication Source by hoisting up an ephemeral znode 'registering' as a RegionServer. The source cluster then streams WALEdits to the Admin Protos method:

{code}
 public ReplicateWALEntryResponse replicateWALEntry(final RpcController controller,
      final ReplicateWALEntryRequest request) throws ServiceException {
{code}

The hbase-indexer relies on other hbase internals like Server so it can get a ZooKeeperWatcher instance and know the 'name' to use for this cut-down server.

Thoughts on how to proceed include:
 
* Better formalize its current digestion of hbase internals; make it so rpcserver is allowed to be used by others, etc.
* Start an actual RegionServer only have it register the AdminProtos Service only -- not AdminProtos and ClientProtos, etc. Then have the hbase-indexer implement an AdminCoprocessor to override the replicateWALEntry method (the Admin CP implementation may need work).

I'll be back....



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)