[
https://issues.apache.org/jira/browse/MAPREDUCE-5689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13853152#comment-13853152
]
Hadoop QA commented on MAPREDUCE-5689:
--------------------------------------
{color:green}+1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12619367/MAPREDUCE-5689.1.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 1 new
or modified test files.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 eclipse:eclipse{color}. The patch built with
eclipse:eclipse.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:green}+1 core tests{color}. The patch passed unit tests in
hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-app.
{color:green}+1 contrib tests{color}. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-MAPREDUCE-Build/4273//testReport/
Console output:
https://builds.apache.org/job/PreCommit-MAPREDUCE-Build/4273//console
This message is automatically generated.
> MRAppMaster does not preempt reducer when scheduled Maps cannot be full filled
> ------------------------------------------------------------------------------
>
> Key: MAPREDUCE-5689
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-5689
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Affects Versions: 3.0.0, 2.2.0
> Reporter: Lohit Vijayarenu
> Attachments: MAPREDUCE-5689.1.patch
>
>
> We saw corner case where Jobs running on cluster were hung. Scenario was
> something like this. Job was running within a pool which was running at its
> capacity. All available containers were occupied by reducers and last 2
> mappers. There were few more reducers waiting to be scheduled in pipeline.
> At this point two mappers which were running failed and went back to
> scheduled state. two available containers were assigned to reducers, now
> whole pool was full of reducers waiting on two maps to be complete. 2 maps
> never got scheduled because pool was full.
> Ideally reducer preemption should have kicked in to make room for Mappers
> from this code in RMContaienrAllocator
> {code}
> int completedMaps = getJob().getCompletedMaps();
> int completedTasks = completedMaps + getJob().getCompletedReduces();
> if (lastCompletedTasks != completedTasks) {
> lastCompletedTasks = completedTasks;
> recalculateReduceSchedule = true;
> }
> if (recalculateReduceSchedule) {
> preemptReducesIfNeeded();
> {code}
> But in this scenario lastCompletedTasks is always completedTasks because maps
> were never completed. This would cause job to hang forever. As workaround if
> we kill few reducers, mappers would get scheduled and caused job to complete.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
