[
https://issues.apache.org/jira/browse/HDDS-16523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dian-Xuan Yang reassigned HDDS-16523:
-------------------------------------
Assignee: Dian-Xuan Yang
> Intermittent failure in TestClass#testMethod
> --------------------------------------------
>
> Key: HDDS-16523
> URL: https://issues.apache.org/jira/browse/HDDS-16523
> Project: Apache Ozone
> Issue Type: Sub-task
> Components: Ozone Manager, test
> Reporter: Dian-Xuan Yang
> Assignee: Dian-Xuan Yang
> Priority: Major
>
> ```
> {code}
> org.apache.hadoop.fs.ozone.TestHSync.testHSyncOpenKeyCommitAfterExpiry -- <<<
> FAILURE!
> java.lang.AssertionError:
> Expecting ArrayList:
> ["hsync-key"]
> to contain:
> ["hsync-key", "key2"]
> but could not find the following element(s):
> ["key2"]
> at
> org.apache.hadoop.fs.ozone.TestHSync.testHSyncOpenKeyCommitAfterExpiry(TestHSync.java:498)
> {code}
> The assertion became effective in HDDS-16084 (commit a9c9caff03), which
> replaced the
> no-op assertThat(2 == getOpenKeyInfo(...).size()) with a real AssertJ
> assertion on key
> names. The race it exposes, however, predates that change.
> getOpenKeyInfo() and getKeyInfo() iterate over the OM tables using
> TypedTable.iterator(),
> which reads directly from RocksDB. The in-memory cache is exposed through a
> separate
> cache iterator. OM acknowledges a write as soon as
> OzoneManagerDoubleBuffer.add()
> queues the response, while the flush thread persists it to RocksDB
> afterwards. Therefore,
> the open key created by the immediately preceding fs.create(key2) can still
> be invisible
> to the iterator, while key1 has already been flushed after an additional
> hsync round trip.
> The fileTable assertion on key1 in the same test is exposed to the same race.
> ```
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
