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

ASF GitHub Bot commented on GIRAPH-1139:
----------------------------------------

Github user neggert commented on the issue:

    https://github.com/apache/giraph/pull/30
  
    There actually is [one instance][1] where I think it's okay to use 
`getHostnamePartitionId`. This happens in `BspServiceMaster.becomeMaster` when 
creating a master bid in ZK, before any `TaskInfo` instance is created.
    
    This does make me realize, though, that I need to make the same change to 
how the task id is set in `BspServiceMaster`.
    
    What about just changing how `taskPartition` is set in `BspService`, like 
so?
    
        this.taskPartition = (int)getApplicationAttempt() * 
conf.getMaxWorkers() + getTaskPartition();
    
    I think this is actually the minimal code change to fix the issue. I don't 
see anywhere in the code that actually cares about the task partition as 
anything other than a unique identifier.
    
    [1]: 
https://github.com/apache/giraph/blob/trunk/giraph-core/src/main/java/org/apache/giraph/master/BspServiceMaster.java#L805


> 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)

Reply via email to