[
https://issues.apache.org/jira/browse/HBASE-27058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542731#comment-17542731
]
Geoffrey Jacoby commented on HBASE-27058:
-----------------------------------------
[~apurtell] - is there an alternate way that already exists to poll for the
success of a major compaction that doesn't rely on the clock? I wasn't able to
find one when I wrote the MaxLookbackIT tests.
It seems odd that there wouldn't be -- "request a server to do a long-running
thing" -> "periodically check with server to see if thing was done" is a pretty
common pattern after all.
> Admin#getLastMajorCompactionTimestamp() doesn't get updated when the
> EnvironmentEdgeManager clock is stopped
> ------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-27058
> URL: https://issues.apache.org/jira/browse/HBASE-27058
> Project: HBase
> Issue Type: Bug
> Affects Versions: 2.5.0
> Reporter: Istvan Toth
> Priority: Major
> Labels: test
>
> In Hbase 2.0-2.4 it is possible to check for a finished compaction by polling
> Admin.getLastMajorCompactionTimestamp() for the table under compaction, even
> when the clock is stopped via EnvironmentEdgeManager.
> However, in Hbase 2.5 the Admin.getLastMajorCompactionTimestamp() will not be
> updated even after the compaction is finished, and getCompactionState()
> returns NONE.
> I am not even sure that this is bug, however, this has broken one of our
> Phoenix tests, and may cause problems for others.
> This is the test code that breaks:
> [https://github.com/apache/phoenix/blob/8aa825ed88828a99d40fdb68eb2f930981cd8a6b/phoenix-core/src/test/java/org/apache/phoenix/util/TestUtil.java#L818]
> Admin.getLastMajorCompactionTimestamp() seems to take the value from the
> Metrics, so I guess that the metrics no longer get updated somewhere when the
> clock is stopped.
> I did not dig deeper than that.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
