hama-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Suraj Menon (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HAMA-639) Superstep Chaining API
Date Thu, 13 Feb 2014 10:12:19 GMT

     [ https://issues.apache.org/jira/browse/HAMA-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Suraj Menon updated HAMA-639:

    Labels: gsoc2014 java scala  (was: )

> Superstep Chaining API
> ----------------------
>                 Key: HAMA-639
>                 URL: https://issues.apache.org/jira/browse/HAMA-639
>             Project: Hama
>          Issue Type: Improvement
>          Components: bsp core
>            Reporter: Suraj Menon
>            Assignee: Suraj Menon
>              Labels: gsoc2014, java, scala
>         Attachments: HAMA-639.patch-v1
> API Requirements:
> * From HAMA framework
> ** A provision to iterate over supersteps
> ** Provide condition state for continuing execution of supersteps
> ** For fault tolerance
> *** The BSP Peer should be able to save complete state of the computation. The state
saved is enough to recover to start its execution from that point in superstep execution.
The state to be saved is as followed:
> **** The next superstep instance to be executed.
> **** In case of loops the condition state of the execution should be provided to indicate
the peer whether it should run the next superstep
> ** Ability to start from the beginning of the superstep
> *** This would be a good point of notifying the peer if it should instantiate the required
message queue implementation used for that superstep.
> *** This could also be a good point to indicate the synchronization barrier that the
superstep chain would be participating in.
> * For BSP Job programmers. - (This is a tricky situation where the programmers are not
as restricted as in Map-Reduce model to express their jobs. However with this freedom comes
the responsibility to maintain the state of your program. )
> ** API should help programmers to express their jobs as a series of Supersteps
> ** API should let them chain their superstep implementation allowing them to share references
to data-structures among the supersteps.
> ** API should let programmer to define the message queue type for the superstep
> ** API should let programmer decide the synchronization barrier that the current superstep
is going to be part of.
> ** API should let programmer save the state of the superstep chain to persistent storage
and retrieve the same such that the program could execute from the beginning of any superstep
execution in the chain for fault tolerance.

This message was sent by Atlassian JIRA

View raw message