[
https://issues.apache.org/jira/browse/FLINK-5892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15984848#comment-15984848
]
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_r113416026
--- Diff:
flink-runtime/src/main/java/org/apache/flink/runtime/jobgraph/JobVertex.java ---
@@ -133,11 +142,15 @@ public JobVertex(String name, JobVertexID id) {
* @param name The name of the new job vertex.
* @param primaryId The id of the job vertex.
* @param alternativeIds The alternative ids of the job vertex.
+ * @param operatorIds The ids of all operators contained in this job
vertex.
+ * @param alternativeOperatorIds The alternative ids of all operators
contained in this job vertex-
*/
- public JobVertex(String name, JobVertexID primaryId, List<JobVertexID>
alternativeIds) {
+ public JobVertex(String name, JobVertexID primaryId, List<OperatorID>
alternativeIds, List<OperatorID> operatorIds, List<OperatorID>
alternativeOperatorIds) {
--- End diff --
Again, generic Type on the third parameter seems off. I also suggest to
introduce line breaks to the parameter list as it is very long. On top of that,
we have a lot of parameter with the same type, which callers always can mix up
easily. This and the number of arguments make me wonder if it would make sense
to just have the actual Ids in the constructor, plus 2 methods to provide the
alternative IDs for the cases that require them?
> 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)
