You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Viraj Jasani (Jira)" <ji...@apache.org> on 2020/07/16 11:07:00 UTC

[jira] [Comment Edited] (HBASE-24459) Move the locateMeta logic from AsyncMetaRegionTableLocator to ConnectionRegistry

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

Viraj Jasani edited comment on HBASE-24459 at 7/16/20, 11:06 AM:
-----------------------------------------------------------------

Few questions:

If we move locateMeta to ConnectionRegistry, MasterRegistry can call MasterProtos.locateMetaRegion(), however, what about ZKConnectionRegistry? Are we expecting default registry to be MasterRegistry with splittable meta work (skimmed through design doc, maybe I missed something related to this)? I think mostly no because many internal cluster connections still do require ZKConnection right?

I hope the intention of this Jira is for clients to hedge the requests in a random order to avoid hot-spotting a single HMaster, hence using Master Registry. Also, with splittable meta, we have no chance of ZK locating meta regions. Is that correct?

 

As of now, logic of *locateMetaRegion() call to active HMaster* is kept in AsyncMetaTableRegionLocator. Is it due to the same reason that we don't have a way for ZK Resitry to provide us meta regions?


was (Author: vjasani):
Few questions:

If we move locateMeta to ConnectionRegistry, MasterRegistry can call MasterProtos.locateMetaRegion(), however, what about ZKConnectionRegistry? Are we expecting default registry to be MasterRegistry with splittable meta work (skimmed through design doc, maybe I missed something related to this)? I think mostly no because many internal cluster connections still do require ZKConnection right?

I hope the intention of this Jira is for clients to hedge the requests in a random order to avoid hot-spotting a single HMaster, hence using Master Registry. Also, with splittable meta, we have no chance of ZK locating meta regions. Is that correct?

> Move the locateMeta logic from AsyncMetaRegionTableLocator to ConnectionRegistry
> --------------------------------------------------------------------------------
>
>                 Key: HBASE-24459
>                 URL: https://issues.apache.org/jira/browse/HBASE-24459
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Duo Zhang
>            Priority: Major
>
> Now the related code is only in AsyncMetaRegionTableLocator, we could make the actually implementation pluggable, so we do not always need to go to the active master.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)