StefanRRichter commented on a change in pull request #7009: [FLINK-10712] 
Support to restore state when using RestartPipelinedRegionStrategy
URL: https://github.com/apache/flink/pull/7009#discussion_r246329731
 
 

 ##########
 File path: 
flink-runtime/src/main/java/org/apache/flink/runtime/executiongraph/failover/FailoverRegion.java
 ##########
 @@ -206,13 +206,21 @@ private void restart(long globalModVersionOfFailover) {
                try {
                        if (transitionState(JobStatus.CREATED, 
JobStatus.RUNNING)) {
                                // if we have checkpointed state, reload it 
into the executions
-                               //TODO: checkpoint support restore part 
ExecutionVertex cp
-                               /**
                                if (executionGraph.getCheckpointCoordinator() 
!= null) {
+                                       // we restart the checkpoint scheduler 
for
+                                       // i) enable new checkpoint could be 
triggered without waiting for last checkpoint expired.
+                                       // ii) ensure the EXACTLY_ONCE 
semantics if needed.
+                                       if 
(executionGraph.getCheckpointCoordinator().isPeriodicCheckpointingConfigured()) 
{
+                                               
executionGraph.getCheckpointCoordinator().stopCheckpointScheduler();
+                                       }
+
                                        
executionGraph.getCheckpointCoordinator().restoreLatestCheckpointedState(
-                                                       
connectedExecutionVertexes, false, false);
+                                                       
connectedExecutionVertexes, false);
 
 Review comment:
   For all cases, as I see it the indexes work as an optimization to just run 
the repartitioning for some tasks. I think it would be ok to drop the 
precondition check because the assignment is only done once in the very 
beginning, so it seems a bit overcautious at this point. If you think that the 
optimization is helpful, we can introduce it with the small changes I proposed. 
However, I doubt that we see real performance benefits in the reassignment, but 
the code is getting more complex, which can make bugs more likely. Maybe you 
could just try out if the is an observable performance difference between using 
the indexes and just reassigning to all tasks?

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on 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

Reply via email to