[ https://issues.apache.org/jira/browse/GIRAPH-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15971326#comment-15971326 ]
ASF GitHub Bot commented on GIRAPH-1139: ---------------------------------------- Github user neggert commented on a diff in the pull request: https://github.com/apache/giraph/pull/30#discussion_r111771953 --- Diff: giraph-core/src/main/java/org/apache/giraph/master/BspServiceMaster.java --- @@ -1734,7 +1735,7 @@ private CheckpointStatus getCheckpointStatus(long superstep) { if (checkpointFrequency == 0) { return CheckpointStatus.NONE; } - long firstCheckpoint = INPUT_SUPERSTEP + 1 + checkpointFrequency; + long firstCheckpoint = INPUT_SUPERSTEP + 1; --- End diff -- This will actually checkpoint before running superstep 0. You're basically checkpointing the input loading work. > Resuming from checkpoint doesn't work > ------------------------------------- > > Key: GIRAPH-1139 > URL: https://issues.apache.org/jira/browse/GIRAPH-1139 > Project: Giraph > Issue Type: Bug > Components: bsp > Affects Versions: 1.2.0 > Reporter: Nic Eggert > > I ran into a couple of issues when trying to get Giraph to resume from > checkpoints (using mapreduce.max.attempts rather than GiraphJobRetryChecker). > * If we just wrote a checkpoint, the master expects the workers to checkpoint > again, while the workers (correctly) clear the checkpointing flag. > * When workers restart, they take their task id from the partition number, > which stays the same across multiple attempts. This gets transferred to the > Netty clientId, and the server starts ignoring messages from restarted > workers because it thinks it processed them already. > I believe I've fixed these issues. I'll send a GitHub PR shortly. -- This message was sent by Atlassian JIRA (v6.3.15#6346)