We have occasionally seen an assert failure in debug builds in in-house testing on the
Raspberry Pi Zero (a 1-CPU system).
%YDB-F-ASSERT, Assert failed in /Distrib/YottaDB/V998_R122/sr_port/wcs_phase2_commit_wait.c
line 337 for expression (cnl->wc_blocked
|| (WBTEST_CRASH_SHUTDOWN_EXPECTED == ydb_white_box_test_case_number))
The update helper reader process waited 1 minute for a specific cache-record in phase2 commit
to be freed up by the update process and timed out.
The 1-CPU system that we have seen this failure is a slow box so this commit gives
such systems 4x the time (4 minutes) before signaling an assert failure.
In production builds, this was a non-issue since the timeout would have returned FALSE from
wcs_phase2_commit_wait() which in turn would have triggered a wcs_recover() (cache recovery)
with no user-visible consequences.
We have occasionally seen an assert failure in debug builds in in-house testing on the Raspberry Pi Zero (a 1-CPU system).
The update helper reader process waited 1 minute for a specific cache-record in phase2 commit to be freed up by the update process and timed out.
The 1-CPU system that we have seen this failure is a slow box so this commit gives such systems 4x the time (4 minutes) before signaling an assert failure.
In production builds, this was a non-issue since the timeout would have returned FALSE from wcs_phase2_commit_wait() which in turn would have triggered a wcs_recover() (cache recovery) with no user-visible consequences.