[
https://issues.apache.org/jira/browse/PHOENIX-7821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Kyle Purtell updated PHOENIX-7821:
-----------------------------------------
Description: {{PhoenixSyncTableToolIT}} asserts that aggressive paging
yields more {{CHUNKS_VERIFIED}} than baseline, but the original approach forced
paging by setting the client RPC timeout to 1–2 ms, which
{{PhoenixSyncTableMapper.createChunkScanner}} then halved to derive the server
page timeout. This causes test flakiness when hardware is either too slow or
too fast. Slow hardware exhausts retries. Fast hardware finishes the scan
within the 2 ms time budget. The fix decouples the two timeouts by teaching
{{createChunkScanner}} to honor an explicitly configured
{{phoenix.server.page.size.ms}} when set, falling back to the old RPC*0.5
heuristic otherwise, preserving production behavior, and updates the test to
enable server-side paging with {{phoenix.server.page.size.ms=1}} while leaving
the client RPC timeout at its default. This deterministically forces a partial
chunk after the first row, satisfying the chunk-count assertion regardless of
cluster speed. (was: `PhoenixSyncTableToolIT` asserts that aggressive paging
yields more `CHUNKS_VERIFIED` than baseline, but the original approach forced
paging by setting the client RPC timeout to 1–2 ms, which
`PhoenixSyncTableMapper.createChunkScanner` then halved to derive the server
page timeout. This causes test flakiness when hardware is either too slow or
too fast. Slow hardware exhausts retries. Fast hardware finishes the scan
within the 2 ms time budget. The fix decouples the two timeouts by teaching
`createChunkScanner` to honor an explicitly configured
`phoenix.server.page.size.ms` when set, falling back to the old RPC*0.5
heuristic otherwise, preserving production behavior, and updates the test to
enable server-side paging with `phoenix.server.page.size.ms=1` while leaving
the client RPC timeout at its default. This deterministically forces a partial
chunk after the first row, satisfying the chunk-count assertion regardless of
cluster speed.)
> PhoenixSyncTableMapper deterministic mid-chunk paging
> -----------------------------------------------------
>
> Key: PHOENIX-7821
> URL: https://issues.apache.org/jira/browse/PHOENIX-7821
> Project: Phoenix
> Issue Type: Sub-task
> Components: core
> Reporter: Andrew Kyle Purtell
> Assignee: Andrew Kyle Purtell
> Priority: Major
> Fix For: 5.4.0, 5.3.1
>
>
> {{PhoenixSyncTableToolIT}} asserts that aggressive paging yields more
> {{CHUNKS_VERIFIED}} than baseline, but the original approach forced paging by
> setting the client RPC timeout to 1–2 ms, which
> {{PhoenixSyncTableMapper.createChunkScanner}} then halved to derive the
> server page timeout. This causes test flakiness when hardware is either too
> slow or too fast. Slow hardware exhausts retries. Fast hardware finishes the
> scan within the 2 ms time budget. The fix decouples the two timeouts by
> teaching {{createChunkScanner}} to honor an explicitly configured
> {{phoenix.server.page.size.ms}} when set, falling back to the old RPC*0.5
> heuristic otherwise, preserving production behavior, and updates the test to
> enable server-side paging with {{phoenix.server.page.size.ms=1}} while
> leaving the client RPC timeout at its default. This deterministically forces
> a partial chunk after the first row, satisfying the chunk-count assertion
> regardless of cluster speed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
