[ 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)