[
https://issues.apache.org/jira/browse/HAMA-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13579229#comment-13579229
]
Suraj Menon commented on HAMA-734:
----------------------------------
I do understand the importance of what you are suggesting. The issue is if we
overload sync we are making things a lot complicated for Superstep API. There
is no peer.sync call in Superstep API. I am trying to solve this as a message
queue feature. We can introduce PeerContext or JobContext object to API to
handle such scenarios.
> Hama Message Manager should be able to delegate the ownership of internal
> message queue on request for future superstep
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: HAMA-734
> URL: https://issues.apache.org/jira/browse/HAMA-734
> Project: Hama
> Issue Type: Improvement
> Reporter: Suraj Menon
>
> Get the ownership of the messagequeue, to improve performance in scenarios
> when a certain set of messages in the queue is to be used in a future
> superstep than the current one. With this feature, the message queue could be
> stored for future without having to read them in the current superstep. The
> framework would initialize and create a new message queue internally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
