[jira] [Commented] (FLINK-1808) Omit sending checkpoint barriers when the execution graph is not running

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

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

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

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

    https://github.com/apache/flink/pull/551#discussion_r27751706
  
    --- Diff: flink-runtime/src/main/scala/org/apache/flink/runtime/jobmanager/StreamCheckpointCoordinator.scala ---
    @@ -82,15 +81,18 @@ class StreamCheckpointCoordinator(val executionGraph: ExecutionGraph,
         case BarrierTimeout =>
           executionGraph.getState match {
             case FAILED | CANCELED | FINISHED =>
    -          log.info("Stopping monitor for terminated job {}", executionGraph.getJobID)
    +          log.info("[FT-Monitor] Stopping monitor for terminated job {}", executionGraph.getJobID)
               self ! PoisonPill
    --- End diff --
    
    Do we need these `[FT-Monitor]` prefixes in the log message? It will be visible that it is coming from the `StreamCheckPointCoordinator` anyway.


> Omit sending checkpoint barriers when the execution graph is not running
> ------------------------------------------------------------------------
>
>                 Key: FLINK-1808
>                 URL: https://issues.apache.org/jira/browse/FLINK-1808
>             Project: Flink
>          Issue Type: Improvement
>          Components: Streaming
>            Reporter: Paris Carbone
>            Assignee: Paris Carbone
>
> Currently the StreamCheckpointCoordinator sends barrier requests even when the executionGraph is in FAILING or RESTARTING status which results in unneeded potential communication and space overhead until the job restarts again. It should therefore simply omit sending barriers requests when the execution graph is not in a RUNNING state. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)