[
https://issues.apache.org/jira/browse/HAMA-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13580921#comment-13580921
]
Suraj Menon commented on HAMA-734:
----------------------------------
I agree.
I have few questions: For message queues like DiskQueue, SpillingQueue, etc.
are you suggesting we won't call prepareRead and writes messages until a read
is needed. If so, how do you configure which superstep to start reading from?
Say in the next algorithm, you want to hold messages for any N supersteps. So
if prepareRead and read is not initiated on these queues, what would
peer.getCurrentMessage return? In case of GraphJobRunner, you need a part of
messages to be read out of the queue. How else can we handle the situation.
BSPMessageMappedStorage is a means by which the framework is letting some
advanced users to handle the messages themselves as demonstrated in
HAMA-704.patch-v1 This is purely for performance.
Instead of setSyncType, how about setSyncMessageQueueBehaviour(PERSIST |
REFRESH | FILTER ..... )? Based on these constants, we can implement
corresponding abstraction over BSPMessageMappedStorage. For a particular
algorithm, I want to keep the top N popular message values I receive. I would
want that as a feature in message handling. I won't implement separate
synchronization scheme again for this feature.
> 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
