huan233usc opened a new pull request, #16965: URL: https://github.com/apache/iceberg/pull/16965
## Problem `TestStructuredStreamingRead3` has two timestamp-based streaming read tests that pick a stream start timestamp in the *future* and then wait for the wall clock to reach it: - `testReadingStreamFromFutureTimetsamp` uses `now + 10000` ms - `testReadingStreamFromTimestampFutureWithExistingSnapshots` uses `now + 2000` ms The wait goes through `TestBase.waitUntilAfter()`, which busy-spins on `System.currentTimeMillis()`. So the future-timestamp test idles for ~10s on every run (it averaged ~16s/run in CI), and because the wait is a spin it pegs a core for the whole duration, contending with the other parallel Gradle test forks. ## Change Anchor the stream's start timestamp to the committed snapshot's `timestampMillis() + 1` instead of a synthetic future instant: - snapshots committed before that point are still excluded; - snapshots committed after `waitUntilAfter(startTimestamp)` returns are still included. The read semantics are unchanged, but no real time has to elapse — `waitUntilAfter` is now handed a near-current timestamp and returns within ~1ms. This matches the existing `testReadingStreamFromTimestamp` / `testReadingStreamFromTimestampOfExistingSnapshot` idiom in the same class. `waitUntilAfter()` is also changed to sleep once for the remaining time instead of busy-spinning, so any remaining future wait no longer burns a core. Applied identically to spark v3.5, v4.0 and v4.1. ### Note on coverage The original `testReadingStreamFromFutureTimetsamp` asserted emptiness after each insert *while the stream was running* (the inserts landed before the future timestamp elapsed). The rewrite commits those snapshots first and starts the stream from a timestamp just after them, so it exercises start-timestamp filtering rather than a running stream crossing the boundary. Verifying the latter deterministically would require controlling snapshot commit timestamps, which has no clean test hook; both paths hit the same start-timestamp boundary check. ## Testing - The two methods pass on spark v3.5, v4.0 and v4.1 (HIVE/async + REST params). - Stress-ran the two methods 20x on v3.5 with the Gradle build cache disabled: 0 failures. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
