scwhittle commented on code in PR #31148:
URL: https://github.com/apache/beam/pull/31148#discussion_r1589246971


##########
runners/google-cloud-dataflow-java/worker/src/main/java/org/apache/beam/runners/dataflow/worker/StreamingDataflowWorker.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(

Review Comment:
   for example if work/workprocessingcontext were combined we could have a 
single
   work.queueCommit(...) which would internally update it's state



##########
runners/google-cloud-dataflow-java/worker/src/main/java/org/apache/beam/runners/dataflow/worker/StreamingDataflowWorker.java:
##########
@@ -965,18 +966,24 @@ private void scheduleWorkItem(
         
WindmillTimeUtils.windmillToHarnessWatermark(workItem.getOutputDataWatermark());
     Preconditions.checkState(
         outputDataWatermark == null || 
!outputDataWatermark.isAfter(inputDataWatermark));
+    WorkProcessingContext workProcessingContext =
+        WorkProcessingContext.builder(
+                computationState.getComputationId(),
+                (computationId, request) ->
+                    Optional.ofNullable(
+                        
metricTrackingWindmillServer.getStateData(computationId, request)))
+            .setWorkCommitter(workCommitter::commit)
+            .setOutputDataWatermark(outputDataWatermark)
+            .setInputDataWatermark(inputDataWatermark)
+            .setSynchronizedProcessingTime(synchronizedProcessingTime)
+            .setWorkItem(workItem)
+            .build();
     Work scheduledWork =

Review 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.



-- 
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: github-unsubscr...@beam.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to