[
https://issues.apache.org/jira/browse/MAPREDUCE-5508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13774702#comment-13774702
]
Chris Nauroth commented on MAPREDUCE-5508:
------------------------------------------
+1 for the patch. Thanks again, Xi.
[~sandyr], assuming that Xi's large scale tests come back showing no memory
leaks, are you also +1 for this patch? If so, then I will commit to branch-1
and branch-1-win.
bq. Does this mean that ... could create either one or two FileSystems objects?
If that code sample is the only thread running, then only one instance is
created, and fs1 == fs2. With multiple threads running, it's
non-deterministic, because the other threads could be running
{{FileSystem#get}} and {{FileSystem#close}} on the same cached instances at
just the right moment. It's possible to get 2 instances created, and fs1 !=
fs2.
It's a good idea to document that {{FileSystem#close}} requires an idempotent
implementation, in scope of a separate jira. In practice,
{{DistributedFileSystem}} does guarantee idempotence via a synchronized close
method and an isRunning flag inside the {{DFSClient}}.
BTW, while researching some of these issues around the cache, I started to
think that we ought to ref-count the instances to better guard against problems
like this. Then, I found HADOOP-4655. Discussion in that issue made an
intentional choice not to ref count in order to preserve
backwards-compatibility with clients that don't call close.
> JobTracker memory leak caused by unreleased FileSystem objects in
> JobInProgress#cleanupJob
> ------------------------------------------------------------------------------------------
>
> Key: MAPREDUCE-5508
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-5508
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: jobtracker
> Affects Versions: 1-win, 1.2.1
> Reporter: Xi Fang
> Assignee: Xi Fang
> Priority: Critical
> Attachments: MAPREDUCE-5508.1.patch, MAPREDUCE-5508.2.patch,
> MAPREDUCE-5508.patch
>
>
> MAPREDUCE-5351 fixed a memory leak problem but introducing another filesystem
> object (see "tempDirFs") that is not properly released.
> {code} JobInProgress#cleanupJob()
> void cleanupJob() {
> ...
> tempDirFs = jobTempDirPath.getFileSystem(conf);
> CleanupQueue.getInstance().addToQueue(
> new PathDeletionContext(jobTempDirPath, conf, userUGI, jobId));
> ...
> if (tempDirFs != fs) {
> try {
> fs.close();
> } catch (IOException ie) {
> ...
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
