Repository navigation
[Java] Bound pending Watch results per poll - #40294
goutamadwant wants to merge 4 commits into
Conversation
|
Checks are failing. Will not request review until checks are succeeding. If you'd like to override that behavior, comment |
|
retest this please |
|
Assigning reviewers: R: @chamikaramj for label java. This pull request likely touches a core component ("core" label). Please review with scrutiny. Note: If you would like to opt out of this review, comment Available commands:
The PR bot will only process comments in the main thread (not review comments). |
|
Reminder, please take a look at this pr: @chamikaramj |
|
Assigning new set of reviewers because Pr has gone too long without review. If you would like to opt out of this review, comment R: @kennknowles for label java. This pull request likely touches a core component ("core" label). Please review with scrutiny. Available commands:
|
kennknowles
left a comment
There was a problem hiding this comment.
This is complex code that I don't know very well, so review will take some time. There may be someone better to review, but I am not sure.
| * when output timestamps advance past the retention floor. It does not impose a count bound on | ||
| * completed keys that share a timestamp still at or above that floor. | ||
| */ | ||
| public Growth<InputT, OutputT, KeyT> withMaxPendingResults(int maxPendingResults) { |
There was a problem hiding this comment.
This should be @Nullable Integer or otherwise have a way of explicitly indicating it is unset.
|
Reminder, please take a look at this pr: @kennknowles @chamikaramj |
|
Hi @goutamadwant, friendly ping to resolve merge conflicts and address one comment so far. Thanks |
|
done @derrickaw |
Addresses the remaining Java pending-result scalability item in #18459.
Watchcurrently keeps every distinct unseen output from a poll in checkpointed pending restriction state. A very large poll can therefore create an oversized state value.What changes
Watch.Growth.withMaxPendingResults(int)API.PollResult.complete(), because its contract promises that the polling function will not be called again.Compatibility and scope
The option is disabled by default, so existing pipelines retain their current behavior. It does not change the restriction coder or persisted state format.
When enabled, the
PollFnmust repeat omitted outputs in subsequent polls and must eventually return a finite set that can drain below the limit. A function that continuously returns more distinct unseen outputs than the limit can keep polling indefinitely; the API documentation and runtime logging make this behavior explicit.The option bounds checkpointed pending outputs. It does not bound the list constructed by the polling function, transient hashes used during selection, or completed keys sharing a retained timestamp. It can be combined with
withTimestampCursor()to time-bound completed-key state when output timestamps advance past the retention floor.This PR covers the Java SDK. Equivalent Python behavior can be tracked separately.
Validation
:sdks:java:core:test --tests 'org.apache.beam.sdk.transforms.WatchTest' --no-build-cache --rerun-tasks- 30 tests passed:runners:direct-java:needsRunnerTests --tests 'org.apache.beam.sdk.transforms.WatchTest.testManyResultsWithPendingLimit' --no-build-cache --rerun-tasks- passed; recovered 300 outputs over three bounded rounds:sdks:java:core:checkstyleMain:sdks:java:core:checkstyleTest:sdks:java:core:spotlessJavaCheck:sdks:java:core:javadoc:sdks:java:core:spotbugsMainThank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:
CHANGES.mdwith noteworthy changes.See the Contributor Guide for more tips on making the review process smoother.
To check the build health, see BUILD_STATUS.md. See CI.md and the workflows README for GitHub Actions details and workflow triggers.