[
https://issues.apache.org/jira/browse/ZOOKEEPER-5080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated ZOOKEEPER-5080:
--------------------------------------
Labels: pull-request-available (was: )
> Flaky test:
> SnapshotAndRestoreCommandTest.testSnapshotAndRestoreCommand_streaming
> ---------------------------------------------------------------------------------
>
> Key: ZOOKEEPER-5080
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-5080
> Project: ZooKeeper
> Issue Type: Bug
> Components: tests
> Affects Versions: 3.10.0
> Reporter: Ivan Khanas
> Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Seen on CI for PR #2435, one failure out of 3262:
> {noformat}
> SnapshotAndRestoreCommandTest.testSnapshotAndRestoreCommand_streaming:168
> -> validateSnapshotMetrics:398 expected: <true> but was: <false>
> {noformat}
> The assertion:
> {noformat}
> assertTrue((Double) metrics.get("avg_snapshottime") > 0.0);
> {noformat}
> avg_snapshottime is fed by ZooKeeperServer.takeSnapshot:
> {noformat}
> long elapsed = Time.currentElapsedTime() - start;
> ServerMetrics.getMetrics().SNAPSHOT_TIME.add(elapsed);
> {noformat}
> elapsed counts whole milliseconds. The database in this test holds a handful
> of
> znodes, so on a fast runner the snapshot finishes inside one millisecond,
> elapsed is 0, and the average never gets above zero. Nothing about the
> snapshot
> went wrong, the clock just was not fine grained enough to notice it happened.
> validateRestoreMetrics one method down has the same problem waiting:
> avg_restore_time > 0.0, fed by RESTORE_TIME.add(elapsed) at
> ZooKeeperServer:644.
> I have not seen it fail yet, but it will eventually, for the same reason.
> The same CI job also failed on master at 4ee3b27be and passed again on the
> next
> commit, so this is not something a branch introduced.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
