[
https://issues.apache.org/jira/browse/MAPREDUCE-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Binglin Chang updated MAPREDUCE-2541:
-------------------------------------
Attachment: MAPREDUCE-2541.v2.patch
Changes:
1. removeMap()removes the map from the cache if index information for this map
is loaded(size>0), index information entry in cache will not be removed if it
is in the loading phrase(size=0), this prevents corruption of totalMemoryUsed
2. add checkTotalMemoryUsed() in IndexCache to check consistency, this is only
used in unit test.
3. add a unit test to construct the race condition, the test failed against
current trunk code, and patched version passed the case on my computer.
The failed test(TestMRCLI) posted by HadoopQA was not caused by this patch.
> Race Condition in IndexCache(readIndexFileToCache,removeMap) causes value of
> totalMemoryUsed corrupt, which may cause TaskTracker continue throw Exception
> ----------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: MAPREDUCE-2541
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-2541
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: tasktracker
> Affects Versions: 0.20.1, 0.21.0, 0.22.0, 0.23.0
> Environment: all
> Reporter: Binglin Chang
> Priority: Critical
> Attachments: MAPREDUCE-2541.patch, MAPREDUCE-2541.v2.patch
>
>
> The race condition goes like this:
> Thread1: readIndexFileToCache() totalMemoryUsed.addAndGet(newInd.getSize())
> Thread2: removeMap() totalMemoryUsed.addAndGet(-info.getSize());
> When SpillRecord is being read from fileSystem, client kills the job,
> info.getSize() equals 0, so in fact totalMemoryUsed is not reduced, but after
> thread1 finished reading SpillRecord, it adds the real index size to
> totalMemoryUsed, which makes the value of totalMemoryUsed wrong(larger).
> When this value(totalMemoryUsed) exceeds totalMemoryAllowed (this usually
> happens when a vary large job with vary large reduce number is killed by the
> user, probably because the user sets a wrong reduce number by mistake), and
> actually indexCache has not cache anything, freeIndexInformation() will throw
> exception constantly.
> A quick fix for this issue is to make removeMap() do nothing, let
> freeIndexInformation() do this job only.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
