use work processing context in work processing #31148
Conversation
|
Checks are failing. Will not request review until checks are succeeding. If you'd like to override that behavior, comment |
|
assign set of reviewers |
|
Assigning reviewers. If you would like to opt out of this review, comment R: @johnjcasey added as fallback since no labels match configuration Available commands:
The PR bot will only process comments in the main thread (not review comments). |
m-trieu
force-pushed
the
mt-work-processing-context
branch
from
32bba62
to
c1a08b5
Compare
| .setInputDataWatermark(inputDataWatermark) | ||
| .setSynchronizedProcessingTime(synchronizedProcessingTime) | ||
| .setWorkItem(workItem) | ||
| .build(); | ||
| Work scheduledWork = |
There was a problem hiding this comment.
We now have WorkItem, WorkProcessingContext, and Work classes.
Does the ProcessingContext benefit from being separate from Work?
If they are valuable distinctions can we think of better names to explain them?
Or perhaps we can have different interfaces and a single class implementing them?
It's odd that process() is a Work member instead of WorkProcessingContext which has commit.
There was a problem hiding this comment.
updated
added Watermarks and ProcessingContext as subclasses of Work and all interactions for work processing goes through Work.java
| @@ -1061,7 +1064,8 @@ private void process( | |||
| if (workItem.getSourceState().getOnlyFinalize()) { | |||
| outputBuilder.setSourceStateUpdates(Windmill.SourceState.newBuilder().setOnlyFinalize(true)); | |||
| work.setState(State.COMMIT_QUEUED); | |||
| workCommitter.commit(Commit.create(outputBuilder.build(), computationState, work)); | |||
| workProcessingContext.queueCommit( | |||
There was a problem hiding this comment.
for example if work/workprocessingcontext were combined we could have a single
work.queueCommit(...) which would internally update it's state
m-trieu
force-pushed
the
mt-work-processing-context
branch
3 times, most recently
from
a2084d6
to
6fadee3
Compare
m-trieu
force-pushed
the
mt-work-processing-context
branch
3 times, most recently
from
97644a2
to
2109108
Compare
|
ready for another look @scwhittle I went with the sort of a SteppedBuilder https://github.com/google/auto/blob/main/value/userguide/builders-howto.md#-create-a-step-builder approach for passing the ProcessingContext out of GrpcDirectGetWorkStream. The receiver just has to |
m-trieu
force-pushed
the
mt-work-processing-context
branch
from
2109108
to
3c0702a
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #31148 +/- ##
=========================================
Coverage 71.42% 71.42%
Complexity 1474 1474
=========================================
Files 909 909
Lines 113707 113707
Branches 1076 1076
=========================================
Hits 81217 81217
Misses 30471 30471
Partials 2019 2019 ☔ View full report in Codecov by Sentry. |
|
Reminder, please take a look at this pr: @johnjcasey |
|
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: @johnjcasey added as fallback since no labels match configuration Available commands:
|
Add work processing context
R: @scwhittle
Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:
addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, commentfixes #<ISSUE NUMBER>instead.CHANGES.mdwith noteworthy changes.See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)
See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.