[
https://issues.apache.org/jira/browse/HADOOP-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902729#action_12902729
]
Eli Collins commented on HADOOP-6833:
-------------------------------------
Hey Todd,
Looks like the test added in this patch is racy, it failed for me after I
looped it for a couple minutes. When System.gc returns it just means the gc has
made a best effort to run, not that it actually has, so in the cases where the
gc hasn't run the test will fail because myArg was not reaped.
The change itself looks correct. Since this is a one-liner and memory leaks
like this are hard to test I'd be OK with a new patch that just fixes the bug
as long as it passes the existing RPC tests. Any other suggestions on how to
add test coverage of course are welcome, doesn't seem worth eg adding a getter
that returns the number of calls.
Thanks,
Eli
> 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-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.
