[
https://issues.apache.org/jira/browse/MAPREDUCE-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Loughran updated MAPREDUCE-437:
-------------------------------------
Fix Version/s: 0.23.0
Status: Patch Available (was: In Progress)
This patch
1. creates a new private FS instance in the job tracker when needed.
2. closes and sets this instance to null when the JT is shutdown.
3. tests both operations.
> JobTracker must ask for a new FS instance and close it when terminated.
> -----------------------------------------------------------------------
>
> Key: MAPREDUCE-437
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-437
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: jobtracker
> Affects Versions: 0.21.0, 0.20.1, 0.22.0, 0.23.0
> Reporter: Steve Loughran
> Assignee: Steve Loughran
> Priority: Minor
> Fix For: 0.23.0
>
> Attachments: MAPREDUCE-437.patch
>
> Original Estimate: 1.5h
> Remaining Estimate: 1.5h
>
> This is something I've been experimenting with HADOOP-3268; I'm not sure what
> the right action is here.
> -currently, the JobTracker does not close() its filesystem when it is shut
> down. This will cause it to leak filesystem references if JobTrackers are
> started and stopped in the same process.
> -The TestMRServerPorts test explicitly closes the filesystem
> jt.fs.close();
> jt.stopTracker();
> -If you move the close() operation into the stopTracker()/terminate logic,
> the filesystem gets cleaned up, but
> TestRackAwareTaskPlacement and TestMultipleLevelCaching fail with a
> FilesystemClosed error (stack traces to follow)
> Should the JobTracker close its filesystem whenever it is terminated? If so,
> there are some tests that need to be reworked slightly to not expect the
> fileystem to be live after the jobtracker is taken down.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira