GJL commented on a change in pull request #9860: [FLINK-14331][runtime] Reset
vertices right after they transition to terminated states
URL: https://github.com/apache/flink/pull/9860#discussion_r333946541
##########
File path:
flink-runtime/src/main/java/org/apache/flink/runtime/scheduler/DefaultScheduler.java
##########
@@ -211,7 +215,8 @@ private Runnable restartTasks(final
Set<ExecutionVertexVersion> executionVertexV
}
private CompletableFuture<?> cancelExecutionVertex(final
ExecutionVertexID executionVertexId) {
- return
executionVertexOperations.cancel(getExecutionVertex(executionVertexId));
+ return
executionVertexOperations.cancel(getExecutionVertex(executionVertexId))
+ .whenComplete((Object ignored, Throwable t) ->
executionSlotAllocator.cancel(executionVertexId));
Review comment:
In the current PR, can it happen that we cancel the slot allocation of a
newer deployment? That is, can it happen that while we wait for the cancel
future to complete, we already request a new slot for one of the vertices that
are being canceled. Currently there can be only one ongoing allocation per
`ExecutionVertex` (see `DefaultExecutionSlotAllocator#pendingSlotAssignments`).
Therefore, I thought it's safest to cancel potential ongoing allocations in
`allocateSlotsAndDeploy()`, i.e., cancel slots before allocating new slots.
----------------------------------------------------------------
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:
[email protected]
With regards,
Apache Git Services
