[
https://issues.apache.org/jira/browse/HBASE-18229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yi Liang updated HBASE-18229:
-----------------------------
Attachment: hbase-18229-master-v2.patch
Hi [~stack]
In the new patch, I add the bestSplitPoint into
GetRegionInfoRequest&Response, and also carry most of your comments.
There are two thing I need to mention
1. As you can see that in RSRpcservices#getRegionInfo
{code}
//region.startRegionOperation(Operation.SPLIT_REGION);
work fine,w/ or w/o
this one
r.flush(true);
r.forceSplit(null);
bestSplitRow = r.checkSplit();
r.clearSplit();
{code}
to get bestSplitRow, I need to flush this region and forceSplit, this logic
copy from RSRpcservices#splitRegion(the old api for split). Not sure why need
to do the flush and forceSplit. And the forceSplit or clearSplit are related to
current SplitProcedure?
2. The splitRegionSync, It follow the logic of mergeRegionSync, but I provide a
API which user can specify timeout and time unit. If it is ok, I will also add
same API for merge when i clean mergeProcedure.
And I have test all related test cases locally, I add some new and did not
remove any existing test cases.
> create new Async Split API to embrace AM v2
> -------------------------------------------
>
> Key: HBASE-18229
> URL: https://issues.apache.org/jira/browse/HBASE-18229
> Project: HBase
> Issue Type: Sub-task
> Components: proc-v2
> Reporter: Yi Liang
> Assignee: Yi Liang
> Attachments: HBase-18229-master-v1.patch, hbase-18229-master-v2.patch
>
>
> See HBASE-18105 for related information, this jira will change the logic of
> Path 1 in splitProcedure, the execution path will be:
> *HBaseAdmin.splitRegionAsync -> MasterKeepAliveConnection.splitRegion ->
> MasterRpcServices.splitRegion -> HMaster.splitRegion->
> AssignmentManager.submitProcedure*
> Master Will no longer as Rs and then Rs turn around to ask master to do the
> split operation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
