Mailing-List: contact dev-help@giraph.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@giraph.apache.org
Date: Mon, 4 Apr 2016 23:42:25 +0000 (UTC)
From: "Hassan Eslami (JIRA)" <jira@apache.org>
To: giraph-dev@incubator.apache.org
Message-ID: <JIRA.12853023.1438971586000.132368.1459813345704@Atlassian.JIRA>
In-Reply-To: <JIRA.12853023.1438971586000@Atlassian.JIRA>
References: <JIRA.12853023.1438971586000@Atlassian.JIRA>
 <JIRA.12853023.1438971586328@arcas>
Subject: [jira] [Commented] (GIRAPH-1027) Improve flow-control on sender
 side
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/GIRAPH-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15225292#comment-15225292 ] 

Hassan Eslami commented on GIRAPH-1027:
---------------------------------------

Thanks Dionysios and Maja for reviewing and committing the diff.

> Improve flow-control on sender side
> -----------------------------------
>
>                 Key: GIRAPH-1027
>                 URL: https://issues.apache.org/jira/browse/GIRAPH-1027
>             Project: Giraph
>          Issue Type: Improvement
>          Components: graph
>            Reporter: Hassan Eslami
>            Assignee: Hassan Eslami
>
> Currently, a sender worker will keep all open requests (and optionally up to a certain number of total open requests) in its own memory. This behavior may cause high memory usage in sender side. Also, since messages can arrive to a worker at an arbitrary rate, receiver may not have the ability to handle all incoming messages, hence we may see a large memory footprint in receiver as well. This diff addresses the problem by limiting the number of open requests per worker in sender side. Also, it provides a cache of unsent requests on sender in case the sender already sent enough messages to another worker but has not received any response back.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)