incubator-hama-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Suraj Menon (Commented) (JIRA)" <>
Subject [jira] [Commented] (HAMA-557) Implement Checkpointing service in Hama
Date Wed, 18 Apr 2012 15:40:44 GMT


Suraj Menon commented on HAMA-557:

Reasons for HAMA-557 requirements are as followed in descending order of their importance:
1. Make checkpointing asynchronous. Would reduce the delay during sync. The checkpoint function
you mentioned would then be optional and could be used only if there is a need to sync with
the ending of checkpointing process for that superstep. The design would be similar to how
spilling is implemented in Hadoop.
2. Update BSPMaster with the checkpointing status of each task with superstep count and checkpoint
file. (We can live without this as we have a convention for naming checkpointing files)
3. Tighter integration of Checkpointer with MessageManager.

I would be putting up a design document for HAMA-551.
> Implement Checkpointing service in Hama
> ---------------------------------------
>                 Key: HAMA-557
>                 URL:
>             Project: Hama
>          Issue Type: Sub-task
>          Components: bsp
>    Affects Versions: 0.6.0
>            Reporter: Suraj Menon
>            Assignee: Suraj Menon
>             Fix For: 0.6.0
> Implement checkpointing service in Apache Hama. My patches for HAMA-533 and HAMA-534
are blocked on this.
> - Checkpointing should be done as messages are either sent or received. I prefer while
receiving messages, as we can achieve some parallelism with asynchronous messages. Please
comment if you differ.
> - BSPMaster should hold the checkpoint status for each task. Checkpoint status includes
superstep count and file information for which checkpointing is complete
> - MessageManager should notify Checkpointer of a new message at BSPPeer.
> - Implement/Reuse MessageBundle class as splitClass in BSPPeerImpl for recovery in initInput.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message