flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FLINK-5892) Recover job state at the granularity of operator
Date Mon, 19 Jun 2017 14:17:00 GMT

    [ https://issues.apache.org/jira/browse/FLINK-5892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16054070#comment-16054070
] 

ASF GitHub Bot commented on FLINK-5892:
---------------------------------------

Github user pnowojski commented on a diff in the pull request:

    https://github.com/apache/flink/pull/3844#discussion_r122718852
  
    --- Diff: flink-tests/src/test/java/org/apache/flink/test/state/operator/restore/keyed/KeyedJob.java
---
    @@ -98,10 +98,9 @@ public static void main(String[] args) throws Exception {
     			.map(new StatefulStringStoringMap(mode, "first"))
     			.setParallelism(4);
     
    -		// TODO: re-enable this when generating the actual 1.2 savepoint
    -		//if (mode == ExecutionMode.MIGRATE || mode == ExecutionMode.RESTORE) {
    -		map.uid("first");
    -		//}
    +		if (mode == ExecutionMode.MIGRATE || mode == ExecutionMode.RESTORE) {
    --- End diff --
    
    I somehow don't like it that is not explained in the commit message what has actually
changed/why was this change required at all. Especially since you have not changed anything
else in the code, it is difficult to understand that.  If nothing else has changed, why do
we need this `if (...)`? If something has changed, shouldn't it be covered by some test?


> 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
>             Fix For: 1.3.0
>
>
> 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.4.14#64029)

Mime
View raw message