yanghua commented on a change in pull request #7571: [FLINK-10724] Refactor
failure handling in check point coordinator
URL: https://github.com/apache/flink/pull/7571#discussion_r276039489
##########
File path:
flink-runtime/src/main/java/org/apache/flink/runtime/checkpoint/PendingCheckpoint.java
##########
@@ -101,7 +100,7 @@
private final CheckpointStorageLocation targetLocation;
/** The promise to fulfill once the checkpoint has been completed. */
- private final CompletableFuture<CompletedCheckpoint>
onCompletionPromise;
+ private final CompletableFuture<CheckpointExecutionResult>
onCompletionPromise;
Review comment:
@StefanRRichter As the design document mentioned, the
`CheckpointExecutionResult ` as a data structure represents the result of
checkpoint execution (we split a full checkpoint behavior into two phases:
trigger and execution). `CheckpointExecutionResult ` will be used in
`CheckpointFailureManager` in the next PR(step 2). I know `CompletableFuture`
can represent a successful case and an exceptional case. However, in my
opinion, using `CheckpointExecutionResult` has two advantage:
* stronger constative(it contains successful checkpoint, failure exception,
failure cause)
* take concerted action with `CheckpointTriggerResult`
About your confusion, We can just use `onCompletionPromise.complete(new
CheckpointExecutionResult(...))` and do not use
`onCompletionPromise.completeExceptionally()`. It will make the implementation
and the source code more clear. What do you think?
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
