[
https://issues.apache.org/jira/browse/GIRAPH-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16049379#comment-16049379
]
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_r122006839
--- Diff: giraph-core/src/main/java/org/apache/giraph/bsp/BspService.java
---
@@ -272,7 +273,7 @@ public BspService(
}
if (LOG.isInfoEnabled()) {
LOG.info("BspService: Connecting to ZooKeeper with job " + jobId +
- ", " + getTaskPartition() + " on " + serverPortList);
+ ", " + getTaskId() + " on " + serverPortList);
--- End diff --
We can't actually set `taskId` before creating the ZK client, since we need
ZK to get the get the application attempt. I changed this to log the partition
instead, which we can get from `conf`.
> 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.4.14#64029)
