[
https://issues.apache.org/jira/browse/HBASE-11467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14081557#comment-14081557
]
Mikhail Antonov commented on HBASE-11467:
-----------------------------------------
Attaching draft version of patch (I'm still working on it) to get initial
feedbacks from those who may be interested. Short overview:
* I didn't yet figure out what to do with ClusterId, which is used as a text
in the secured setup for the handshake. So for now actual code inside
connection manager is using default cluster id, but as part of this change I
did make an attempt to expose ClusterId at the rest endpoint (for that purpose
I moved several classes from hbase-server to hbase-client, namely Client,
Cluster and Response, and created REST resource and model in hbase-server
module. All this code isn't being used now).
* MasterAddressesProvider interface is assumed to provide callers with the
address of next master he should attempt to contact, as well as return the full
list of all known possible masters. It does not guarantee that next master
returned to caller will be up and running at the time callers decides to
connect it, so caller still expected to validate it itself (that's what
happening in HConnectionImplementation). Also caller shall not assume that call
to get next active master costs nothing, as implementation might be doing
network-based lookup.
* ConfigBasedMasterAddresses provider does simple round robin across all
masters he knows of from the config file. Assumptions are that 1) caching of
retrieved locations is handled at higher level, in HConnectionImplementation,
and this class doesn't care 2) all masters are using the same RPC port, which
is retrieved from hbase-site.com, and it's not part of masters quorum property
3) this class doesn't record information about failed servers, handling of
failed servers is done separately in RpcClient.FailedServers. This part
actually needs to be refined.
* HConnectionKey was modified to include now masters quorum string and not
ZK-related stuff.
* Few new RPC calls (and message types) were added to MasterProtos
* Unfortunately, I had to do quite a bit of changes in scaffolding code around
mini HBase cluster, because for what I'm doing here I need everyone to know
actual master's RPC port, and currently in mini HBase cluster it binds to
ephemeral port .
What else..The basic tests (including few humble tests I wrote) are passing,
but some LargeTests, including master failover tests, are broken, so I'm
working on them now. Some more notes to emphasize on testing.
Now there are 2 working tests added (1 for config based master addresses
provider, and one for RpcRegistry itself, and 1 test for ClusterIdResource REST
endpoint, but latter one isn't being used.
> New impl of Registry interface not using ZK + new RPCs on master protocol
> -------------------------------------------------------------------------
>
> Key: HBASE-11467
> URL: https://issues.apache.org/jira/browse/HBASE-11467
> Project: HBase
> Issue Type: Sub-task
> Components: Client, Consensus, Zookeeper
> Reporter: Mikhail Antonov
> Assignee: Mikhail Antonov
> Fix For: 2.0.0
>
> Attachments: HBASE-11467.patch
>
>
> Currently there' only one implementation of Registry interface, which is
> using ZK to get info about meta. Need to create implementation which will be
> using RPC calls to master the client is connected to.
> That includes adding several new methods to master RPC protocol:
> - GetMetaRegionLocation
> - IsTableOnlineState
> - GetCurrentNrHRS
> Additionally, new HTTP endpoint would be added to the master, so anyone can
> request ClusterId without any authentication.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
