Dian-Xuan Yang created HDDS-16523:
-------------------------------------
Summary: 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
```
{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]
