XComp commented on pull request #15049: URL: https://github.com/apache/flink/pull/15049#issuecomment-802708237
> My other question, @XComp @zentol, if AdaptiveScheduler re-creates the ExecutionGraph repeatedly during execution of a job will we have one `JobID` with multiple `ExecutionGraphInfo`s then? And then each of the `ExecutionGraphInfo`s will have multple exceptions? Will we need to make [ExecutionGraphStore.get(jobId)](https://github.com/XComp/flink/blob/b7e93fd671a0dc0e7ba919a447ca9e51bb451fdd/flink-runtime/src/main/java/org/apache/flink/runtime/dispatcher/ExecutionGraphInfoStore.java#L49) return a list of `ExecutionGraphInfo`s (and all the other similar changes)? > > It seems like this PR's REST API otherwise will work with one job -> many ExecutionGraphInfo -> many exceptions? Would that work in the GUI? The initial motivation of `ExecutionGraphInfo` was to encapsulate the issue having multiple `AccessExecutionGraph` instances in place for a given job. The `DefaultScheduler` only has one `AccessExecutionGraph` instance during the job's lifetime. The `AdaptiveScheduler` might come up with multiple instances of `AccessExecutionGraph` as it might run into global failovers. Instead of having multiple `ExecutionGraphInfo` instances, you could extend `ExecutionGraphInfo` to support multiple `AccessExecutionGraph` instances. Alternatively, one could come up with a `CompositeExecutionGraph` implementing `AccessExecutionGraph` which aggregates the underlying collection of `ArchivedExecutionGraphs`. That might reduce the amount of code changes that are necessary to be done in the REST handlers. -- 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]
