[
https://issues.apache.org/jira/browse/HBASE-16668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang resolved HBASE-16668.
-------------------------------
Fix Version/s: (was: 3.0.0-beta-2)
Assignee: (was: Stephen Yuan Jiang)
Resolution: Implemented
At least in 3.0.0, call get on the return Future object is enough for determine
whether the merges are merged. We will wait until the procedure at master side
finishes and then mark the return future as completed.
Resolve as implemented.
> Admin class should have a synchronous Admin#mergeRegions* method
> -----------------------------------------------------------------
>
> Key: HBASE-16668
> URL: https://issues.apache.org/jira/browse/HBASE-16668
> Project: HBase
> Issue Type: Bug
> Affects Versions: 2.0.0
> Reporter: Jonathan Hsieh
> Priority: Major
> Attachments: 16668.v1.txt
>
>
> In trunk from HBASE-14552, we have deprecated {{void Admin#mergeRegions}} (in
> 1.x this was an asynchronous call) and replaced it with {{Future<Void>
> Admin#mergeRegionsAsync}} which is clearly async.
> This leaves us only with the async version.
> We should have an easy way to make {{mergeRegions}} or an equivalant behave
> synchronously.
> For normal java Futures, we could just call the future's {{get()}} method.
> Unforutnately, the future this method returns doesn't follow java Future
> convention and throws Unimplemented operation when a plain {{get()}} is
> called and makes the api harder to use and read. We could make this future
> act more normally, and have the timeout throw an InterruptedException.
> Alternately, we could expose a new method in {{Admin}} that behaves
> synchronously such as {{HBaseAdmin#mergeRegionsSync}}. The caveat here is
> that we shouldn't use the name {{#mergeRegions}} since it exists in 1.x with
> async semantics.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
