Details
Major Description
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
- 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:
- 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.