Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Message-ID: <32445652.10761282848534970.JavaMail.jira@thor>
Date: Thu, 26 Aug 2010 14:48:54 -0400 (EDT)
From: "Todd Lipcon (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Subject: [jira] Updated: (HADOOP-6833) IPC leaks call parameters when
 exceptions thrown
In-Reply-To: <21655383.3791277174455275.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HADOOP-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Todd Lipcon updated HADOOP-6833:
--------------------------------

    Attachment: hadoop-6833.txt

Here's the same patch minus the unit test.

As for manual/cluster testing, we've been running with this fix in HBase's copy of RPC for a couple months. We used to eventually run out of RAM, heap analysis showed this was the problem. This fix got rid of the issue.

> IPC leaks call parameters when exceptions thrown
> ------------------------------------------------
>
>                 Key: HADOOP-6833
>                 URL: https://issues.apache.org/jira/browse/HADOOP-6833
>             Project: Hadoop Common
>          Issue Type: Bug
>    Affects Versions: 0.20.2, 0.21.0, 0.22.0
>            Reporter: Todd Lipcon
>            Assignee: Todd Lipcon
>            Priority: Blocker
>         Attachments: hadoop-6833.txt, hadoop-6833.txt
>
>
> HADOOP-6498 moved the calls.remove() call lower into the SUCCESS clause of receiveResponse(), but didn't put a similar calls.remove into the ERROR clause. So, any RPC call that throws an exception ends up orphaning the Call object in the connection's "calls" hashtable. This prevents cleanup of the connection and is a memory leak for the call parameters.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.