[ 
https://issues.apache.org/jira/browse/FLINK-8732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372786#comment-16372786
 ] 

ASF GitHub Bot commented on FLINK-8732:
---------------------------------------

Github user GJL commented on a diff in the pull request:

    https://github.com/apache/flink/pull/5548#discussion_r169943180
  
    --- Diff: 
flink-runtime/src/main/java/org/apache/flink/runtime/executiongraph/Execution.java
 ---
    @@ -377,14 +377,14 @@ public boolean scheduleForExecution() {
         * @param queued Flag to indicate whether the scheduler may queue this 
task if it cannot
         *               immediately deploy it.
         * @param locationPreferenceConstraint constraint for the location 
preferences
    -    * @throws IllegalStateException Thrown, if the vertex is not in 
CREATED state, which is the only state that permits scheduling.
    +    * @returns Future which is completed once the Execution has been 
deployed
    --- End diff --
    
    Should be `@return` not `@returns`.


> Cancel scheduling operation when cancelling the ExecutionGraph
> --------------------------------------------------------------
>
>                 Key: FLINK-8732
>                 URL: https://issues.apache.org/jira/browse/FLINK-8732
>             Project: Flink
>          Issue Type: Bug
>          Components: Distributed Coordination
>    Affects Versions: 1.5.0
>            Reporter: Till Rohrmann
>            Assignee: Till Rohrmann
>            Priority: Major
>              Labels: flip-6
>             Fix For: 1.5.0
>
>
> With the Flip-6 changes and the support for queued scheduling, the 
> {{ExecutionGraph}} must be able to handle cancellation calls when it is not 
> yet fully scheduled. This is for example the case when waiting for new 
> containers.
> A cancellation will cancel all {{Executions}}. As a result, available slots 
> can get assigned to other {{Executions}} (already canceled). Since the slot 
> cannot be assigned to this slot because it's already canceled, this can fail 
> the overall eager scheduling operation. The scheduling result callback will 
> then trigger a global fail operation. This can happen before all 
> {{Executions}} have been released and, thus, when the {{ExecutionGraph}} is 
> still in the state {{CANCELLING}}. The result is that the {{ExecutionGraph}} 
> goes into the state {{FAILING}} and then {{FAILED}}.
> In order to solve this problem, I propose to keep track of the scheduling 
> operation and cancelling the result future when a concurrent {{suspend}}, 
> {{cancel}} or {{fail}} call happens.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to