[
https://issues.apache.org/jira/browse/MAPREDUCE-6618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15120198#comment-15120198
]
Jason Lowe commented on MAPREDUCE-6618:
---------------------------------------
Sorry, I should have been more clear. I don't think we need to initialize
these various fields to null because that's what Java does automatically.
(Doesn't hurt, just not sure it helps anything.) Instead what I was asking was
whether it would be prudent to set things to null as we close them. For
example, a code idiom like this template:
{code}
if (x != null) {
x.close();
x = null;
}
{code}
This helps guard against doing extra work in cases of a double-close or someone
trying to continue using the object after it has been closed. I'm simply used
to seeing that sort of pattern, so when I saw the code checking for null before
the close I wondered out loud whether we should be also setting the fields to
null as part of that close processing.
> YarnClientProtocolProvider leaking the YarnClient thread.
> ----------------------------------------------------------
>
> Key: MAPREDUCE-6618
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6618
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Reporter: Xuan Gong
> Assignee: Xuan Gong
> Attachments: MAPREDUCE-6618.1.patch, MAPREDUCE-6618.2.patch,
> MAPREDUCE-6618.3.patch, MAPREDUCE-6618.4.patch
>
>
> YarnClientProtocolProvider creates YarnRunner which includes
> ResourceMgrDelegate. In ResourceMgrDelegate, we would initiate and start
> yarnclient. The yarnClient thread would be leaked due to
> {code}
> @Override
> public void close(ClientProtocol clientProtocol) throws IOException {
> // nothing to do
> }
> {code} in YarnClientProtocolProvider
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
