[
https://issues.apache.org/jira/browse/IGNITE-29192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Werner updated IGNITE-29192:
-----------------------------------
Description:
https://ci2.ignite.apache.org/test/1116565989146548944?currentProjectId=IgniteTests24Java8&branch=%3Cdefault%3E
*Root cause*
The test runs in two phases on the same persistence directory. In phase 1 it
logs a CheckpointRecord, saves the returned WALPointer start (which lands in
WAL segment 0), writes 1000 pages across 20 simulated checkpoints with
AlwaysWriteFullPages=true and WalMode=LOG_ONLY, then stops the node. In phase 2
it restarts the node and calls wal.replay(start).
The test never sets maxWalArchiveSize, so the default 1 GiB applies and the
background FileCleaner worker is active. Because real checkpoints are disabled
(dbMgr.enableCheckpoints(false)), the cleaner's lastCheckpointPtr lags behind,
and it legitimately deletes segment 0 (where start lives) as "obsolete" before
the node stops. On restart the archive starts at segment 1, so
RecordsIterator.init() throws IgniteCheckedException: WAL history is too short
[descs[0].idx=1, start.idx=0].
This is a timing-dependent race: on fast CI agents the cleaner wins the race
and the test fails; on slower runs segment 0 survives and the test passes.
*Fix*
One line in getConfiguration — disable WAL archive truncation so the cleaner
never starts and segment 0 is guaranteed to survive until phase 2:
.setDataStorageConfiguration(
new DataStorageConfiguration()
.setCheckpointFrequency(500)
.setWalMode(WALMode.LOG_ONLY)
.setAlwaysWriteFullPages(true)
.setMaxWalArchiveSize(DataStorageConfiguration.UNLIMITED_WAL_ARCHIVE)
// add this
.setDefaultDataRegionConfiguration(...))
This is the same pattern already used by sibling PDS tests that replay WAL
after a restart (IgnitePdsStartWIthEmptyArchive,
IgnitePdsReserveWalSegmentsTest, IgniteLocalWalSizeTest,
IgniteWalRebalanceLoggingTest). It is safe for all five tests in the class —
none depend on archive truncation, each runs in a clean persistence dir wiped
by afterTest, and the largest WAL footprint is a few hundred MiB.
was:https://ci2.ignite.apache.org/test/1116565989146548944?currentProjectId=IgniteTests24Java8&branch=%3Cdefault%3E
> Fix flaky
> IgnitePdsCheckpointSimulationWithRealCpDisabledTest.testCheckpointSimulationMultiThreaded
> ---------------------------------------------------------------------------------------------------
>
> Key: IGNITE-29192
> URL: https://issues.apache.org/jira/browse/IGNITE-29192
> Project: Ignite
> Issue Type: Bug
> Reporter: Dmitry Werner
> Assignee: Dmitry Werner
> Priority: Minor
>
> https://ci2.ignite.apache.org/test/1116565989146548944?currentProjectId=IgniteTests24Java8&branch=%3Cdefault%3E
> *Root cause*
> The test runs in two phases on the same persistence directory. In phase 1 it
> logs a CheckpointRecord, saves the returned WALPointer start (which lands in
> WAL segment 0), writes 1000 pages across 20 simulated checkpoints with
> AlwaysWriteFullPages=true and WalMode=LOG_ONLY, then stops the node. In phase
> 2 it restarts the node and calls wal.replay(start).
> The test never sets maxWalArchiveSize, so the default 1 GiB applies and the
> background FileCleaner worker is active. Because real checkpoints are
> disabled (dbMgr.enableCheckpoints(false)), the cleaner's lastCheckpointPtr
> lags behind, and it legitimately deletes segment 0 (where start lives) as
> "obsolete" before the node stops. On restart the archive starts at segment 1,
> so RecordsIterator.init() throws IgniteCheckedException: WAL history is too
> short [descs[0].idx=1, start.idx=0].
> This is a timing-dependent race: on fast CI agents the cleaner wins the race
> and the test fails; on slower runs segment 0 survives and the test passes.
> *Fix*
> One line in getConfiguration — disable WAL archive truncation so the cleaner
> never starts and segment 0 is guaranteed to survive until phase 2:
> .setDataStorageConfiguration(
> new DataStorageConfiguration()
> .setCheckpointFrequency(500)
> .setWalMode(WALMode.LOG_ONLY)
> .setAlwaysWriteFullPages(true)
> .setMaxWalArchiveSize(DataStorageConfiguration.UNLIMITED_WAL_ARCHIVE)
> // add this
> .setDefaultDataRegionConfiguration(...))
> This is the same pattern already used by sibling PDS tests that replay WAL
> after a restart (IgnitePdsStartWIthEmptyArchive,
> IgnitePdsReserveWalSegmentsTest, IgniteLocalWalSizeTest,
> IgniteWalRebalanceLoggingTest). It is safe for all five tests in the class —
> none depend on archive truncation, each runs in a clean persistence dir wiped
> by afterTest, and the largest WAL footprint is a few hundred MiB.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
