hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eli Collins (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HADOOP-6833) IPC leaks call parameters when exceptions thrown
Date Fri, 27 Aug 2010 02:43:15 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12903195#action_12903195
] 

Eli Collins commented on HADOOP-6833:
-------------------------------------

+1    

Here are the test-patch results. Not sure why it -1 javadoc, ant javadoc|javadoc-dev are clean.

{noformat}
     [exec] -1 overall.  
     [exec] 
     [exec]     +1 @author.  The patch does not contain any @author tags.
     [exec] 
     [exec]     -1 tests included.  The patch doesn't appear to include any new or modified
tests.
     [exec]                         Please justify why no new tests are needed for this patch.
     [exec]                         Also please list what manual steps were performed to verify
this patch.
     [exec] 
     [exec]     -1 javadoc.  The javadoc tool appears to have generated 1 warning messages.
     [exec] 
     [exec]     +1 javac.  The applied patch does not increase the total number of javac compiler
warnings.
     [exec] 
     [exec]     +1 findbugs.  The patch does not introduce any new Findbugs warnings.
     [exec] 
     [exec]     +1 release audit.  The applied patch does not increase the total number of
release audit warnings.
{noformat}


> 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.


Mime
View raw message