[
https://issues.apache.org/jira/browse/PHOENIX-7821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Kyle Purtell resolved PHOENIX-7821.
------------------------------------------
Fix Version/s: (was: 5.4.0)
(was: 5.3.1)
Assignee: (was: Andrew Kyle Purtell)
Resolution: Duplicate
I see PHOENIX-7799 came in ahead of this one.
> 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
> Priority: Major
>
> {{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)
