[ https://issues.apache.org/jira/browse/FLINK-7216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16094583#comment-16094583 ]
ASF GitHub Bot commented on FLINK-7216: --------------------------------------- Github user aljoscha commented on a diff in the pull request: https://github.com/apache/flink/pull/4364#discussion_r128477775 --- Diff: flink-runtime/src/test/java/org/apache/flink/runtime/executiongraph/ExecutionGraphTestUtils.java --- @@ -189,6 +189,35 @@ public static void finishAllVertices(ExecutionGraph eg) { } } + /** + * Turns a newly scheduled execution graph into a state where all vertices run. + * This waits until all executions have reached state 'DEPLOYING' and then switches them to running. + */ + public static void waitUntilDeployedAndSwitchToRunning(ExecutionGraph eg, long timeout) throws TimeoutException { + // wait until everything is running + for (ExecutionVertex ev : eg.getAllExecutionVertices()) { + final Execution exec = ev.getCurrentExecutionAttempt(); + waitUntilExecutionState(exec, ExecutionState.DEPLOYING, timeout); + } + + // Note: As ugly as it is, we need this minor sleep, because between switching + // to 'DEPLOYED' and when the 'switchToRunning()' may be called lies a race check + // against concurrent modifications (cancel / fail). We can only switch this to running + // once that check is passed. For the actual runtime, this switch is triggered by a callback + // from the TaskManager, which comes strictly after that. For tests, we use mock TaskManagers + // which cannot easily tell us when that condition has happened, unfortunately. + try { + Thread.sleep(2); --- End diff -- 😢 but it seems there's no way around it. Could this lead to flaky tests? > ExecutionGraph can perform concurrent global restarts to scheduling > ------------------------------------------------------------------- > > Key: FLINK-7216 > URL: https://issues.apache.org/jira/browse/FLINK-7216 > Project: Flink > Issue Type: Bug > Components: Distributed Coordination > Affects Versions: 1.2.1, 1.3.1 > Reporter: Stephan Ewen > Assignee: Stephan Ewen > Priority: Blocker > Fix For: 1.4.0, 1.3.2 > > > Because ExecutionGraph restarts happen asynchronously and possibly delayed, > it can happen in rare corner cases that two restarts are attempted > concurrently, in which case some structures on the Execution Graph undergo a > concurrent access: > Sample stack trace: > {code} > WARN org.apache.flink.runtime.executiongraph.ExecutionGraph - Failed > to restart the job. > java.lang.IllegalStateException: SlotSharingGroup cannot clear task > assignment, group still has allocated resources. > at > org.apache.flink.runtime.jobmanager.scheduler.SlotSharingGroup.clearTaskAssignment(SlotSharingGroup.java:78) > at > org.apache.flink.runtime.executiongraph.ExecutionJobVertex.resetForNewExecution(ExecutionJobVertex.java:535) > at > org.apache.flink.runtime.executiongraph.ExecutionGraph.restart(ExecutionGraph.java:1151) > at > org.apache.flink.runtime.executiongraph.restart.ExecutionGraphRestarter$1.call(ExecutionGraphRestarter.java:40) > at akka.dispatch.Futures$$anonfun$future$1.apply(Future.scala:95) > at > scala.concurrent.impl.Future$PromiseCompletingRunnable.liftedTree1$1(Future.scala:24) > at > scala.concurrent.impl.Future$PromiseCompletingRunnable.run(Future.scala:24) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:748) > {code} > The solution is to strictly guard against "subsumed" restarts via the > {{globalModVersion}} in a similar way as we fence local restarts against > global restarts. -- This message was sent by Atlassian JIRA (v6.4.14#64029)