[
https://issues.apache.org/jira/browse/FLINK-5892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15988644#comment-15988644
]
ASF GitHub Bot commented on FLINK-5892:
---------------------------------------
Github user zentol commented on a diff in the pull request:
https://github.com/apache/flink/pull/3770#discussion_r113903349
--- Diff:
flink-runtime/src/main/java/org/apache/flink/runtime/jobgraph/JobVertex.java ---
@@ -125,6 +132,8 @@ public JobVertex(String name) {
public JobVertex(String name, JobVertexID id) {
this.name = name == null ? DEFAULT_NAME : name;
this.id = id == null ? new JobVertexID() : id;
+ this.operatorIDs.add(new OperatorID(this.id.getLowerPart(),
this.id.getUpperPart()));
+ this.operatorIdsAlternatives.add(null);
--- End diff --
We only need a single alternative ID for each operatorID, the one set using
`setUIDHash()`.
For savepoints created with 1.3 other alternatives aren't required since
1.3 doesn't use the old hasher.
1.0-1.2 savepoints are converted to the 1.3 format using the alternative
job vertex IDs (see `SavepointV2#convertToOperatorStateSavepointV2`), which is
why we can't remove them. After the conversion however the are identical to a
1.3 savepoint.
> 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)