Return-Path: X-Original-To: apmail-hama-dev-archive@www.apache.org Delivered-To: apmail-hama-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 366F2EB0D for ; Mon, 18 Feb 2013 23:09:13 +0000 (UTC) Received: (qmail 65850 invoked by uid 500); 18 Feb 2013 23:09:13 -0000 Delivered-To: apmail-hama-dev-archive@hama.apache.org Received: (qmail 65816 invoked by uid 500); 18 Feb 2013 23:09:13 -0000 Mailing-List: contact dev-help@hama.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hama.apache.org Delivered-To: mailing list dev@hama.apache.org Received: (qmail 65711 invoked by uid 99); 18 Feb 2013 23:09:12 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Feb 2013 23:09:12 +0000 Date: Mon, 18 Feb 2013 23:09:12 +0000 (UTC) From: "Edward J. Yoon (JIRA)" To: dev@hama.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HAMA-734) Hama Message Manager should be able to delegate the ownership of internal message queue on request for future superstep MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HAMA-734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13580886#comment-13580886 ] Edward J. Yoon commented on HAMA-734: ------------------------------------- I didn't look at closely -- how iterative algorithm can be implemented using superstep API -- but as you described above, superstep API has no sync() method (maybe like pregel) and multi supersteps should be defined in job configuration right? If we have a plan to introduce additional types of synchronization in the future, the type of sync also should be able to specified in job configuration. > 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