[
https://issues.apache.org/jira/browse/HBASE-27058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17542729#comment-17542729
]
Andrew Kyle Purtell edited comment on HBASE-27058 at 5/27/22 12:33 AM:
-----------------------------------------------------------------------
[~gjacoby][~stoty]
I think it is expected behavior if an EnvironmentEdge is injected that stops
the clock, that the timestamp will not change, because whatever assignment is
made to that metric, the clock will not have advanced from the last check,
because the injected clock is not advancing. We did a pass over the code and
ensured we were using EnvironmentEdgeManager#getCurrent instead of
System#currentTimeMillis wherever possible and this stands to reason is a
consequence. (In fact its no doubt time for another sweep.)
Can you use an IncrementingEnvironmentEdge instead of ManualEnvironmentEdge
and/or advance the clock as required?
Or perhaps we can figure out how you can spy on a compaction request using
mockito and have something you can wait on that way.
was (Author: apurtell):
[~gjacoby][~stoty]
I think it is expected behavior if an EnvironmentEdge is injected that stops
the clock, that the timestamp will not change, because whatever assignment is
made to that metric, the clock will not have advanced from the last check,
because the injected clock is not advancing. We did a pass over the code and
ensured we were using EnvironmentEdgeManager#getCurrent instead of
System#currentTimeMillis wherever possible and this stands to reason is a
consequence. (In fact its no doubt time for another sweep.)
Can you use an IncrementingEnvironmentEdge instead of ManualEnvironmentEdge
and/or advance the clock as required?
> 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)
