[
https://issues.apache.org/jira/browse/FLINK-5892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15988897#comment-15988897
]
ASF GitHub Bot commented on FLINK-5892:
---------------------------------------
Github user StefanRRichter commented on a diff in the pull request:
https://github.com/apache/flink/pull/3770#discussion_r113924290
--- Diff:
flink-runtime/src/main/java/org/apache/flink/runtime/executiongraph/ExecutionJobVertex.java
---
@@ -139,6 +158,10 @@ public ExecutionJobVertex(
this.serializedTaskInformation = null;
this.taskVertices = new ExecutionVertex[numTaskVertices];
+ List<OperatorID> opIDs = jobVertex.getOperatorIDs();
+ this.operatorIDs = opIDs.toArray(new OperatorID[opIDs.size()]);
--- End diff --
How about making `operatorIDs` an immutable list instead of an array. I
think all the operations you perform could also run on an array list and we
could enforce immutability so that nobody is tempted to modify the inner state
of the original array (e.g. to reverse the element order for convenience in
other parts of the code). Same for the alternative Ids.
> Recover job state at the granularity of operator
> ------------------------------------------------
>
> Key: FLINK-5892
> URL: https://issues.apache.org/jira/browse/FLINK-5892
> Project: Flink
> Issue Type: New Feature
> Components: State Backends, Checkpointing
> Reporter: Guowei Ma
> Assignee: Guowei Ma
>
> JobGraph has no `Operator` info so `ExecutionGraph` can only recovery at the
> granularity of task.
> This leads to the result that the operator of the job may not recover the
> state from a save point even if the save point has the state of operator.
>
> https://docs.google.com/document/d/19suTRF0nh7pRgeMnIEIdJ2Fq-CcNVt5_hR3cAoICf7Q/edit#.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
