[
https://issues.apache.org/jira/browse/HBASE-27077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544454#comment-17544454
]
Geoffrey Jacoby commented on HBASE-27077:
-----------------------------------------
I don't have an opinion between putting it on Admin vs HBTU, however, I thought
the consensus of the community was to discourage using HBTU directly to do
things vs using Admin?
Also I believe the HBTU is currently marked LimitedPrivate(PHOENIX) instead of
LimitedPrivate(COPROC), and there's a non-Phoenix internal coproc at my dayjob
that does similar tricks with compaction and so has a similar need for testing
compaction in an IT test.
As I said, I'm fine with it being either place, I just want to make sure that
wherever it goes isn't on a path for deprecation in the near future. Thanks!
> Synchronous API calls for Split, Merge, and Compaction operations for testing
> -----------------------------------------------------------------------------
>
> Key: HBASE-27077
> URL: https://issues.apache.org/jira/browse/HBASE-27077
> Project: HBase
> Issue Type: Improvement
> Reporter: Istvan Toth
> Priority: Major
>
> While generally split, merge, and compaction operations are too slow for
> synchrounous calls, for many tests we do need to wait until these operations
> are finished to be able to check their results.
> At least in the Phoenix tests, we also need to to do this while the
> EnvirenmentEdge clock is stopped.
> The polling method Admin.getLastMajorCompactionTimestamp() the we used for
> compactions has stopped working with EnvironmentEdgeManager in 2.5, see
> HBASE-27058 for details. We've also had similar issues in the past, where new
> versions made the previous workaround for synchronous operations fail.
> A longer-term solution for the problem would be having Synchronous API calls
> for testing, which block on the client side until the requested operation is
> finished.
> These could be added as variants to Admin / AsyncAdmin, or could be somewhere
> else, it doesn't really matter, as these would not be well suited for
> production use anyway.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
