[
https://issues.apache.org/jira/browse/MAPREDUCE-2324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13065339#comment-13065339
]
Robert Joseph Evans commented on MAPREDUCE-2324:
------------------------------------------------
I have not really thought about this yet in reference to MR-279. I am more
concerned about a sustaining release for the 0.20.20X line. And then look at
porting the functionality to MR-279.
I am not sure that it even applies to MR-279 because of how scheduling is
different. My understanding is that the ApplicationMaster will make a request
to the ResourceManager for a set of nodes that meet criteria X (I believe that
disk space is one of the criteria you can request but it is currently ignored).
The ResourceManager looks at all of the nodes available and hands back a list
of nodes that best match the given criteria. So the ApplicationMaster has no
idea at all which, if any nodes were considered and rejected, or even what all
of the nodes in the system are. If we wanted to keep track of individual nodes
it would either have to be on the ResourceManager, which does have resource
constraints, or in the ApplicationMaster which would now need a list of all
nodes in the cluster along with which nodes were tried and rejected for which
reasons.
In fact mapreduce.reduce.input.limit is not in the MR-279 code base at all, so
for MR-279 we need to think about resource limits and scheduling more generally.
> Job should fail if a reduce task can't be scheduled anywhere
> ------------------------------------------------------------
>
> Key: MAPREDUCE-2324
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-2324
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Affects Versions: 0.20.2, 0.20.205.0
> Reporter: Todd Lipcon
> Assignee: Robert Joseph Evans
>
> If there's a reduce task that needs more disk space than is available on any
> mapred.local.dir in the cluster, that task will stay pending forever. For
> example, we produced this in a QA cluster by accidentally running terasort
> with one reducer - since no mapred.local.dir had 1T free, the job remained in
> pending state for several days. The reason for the "stuck" task wasn't clear
> from a user perspective until we looked at the JT logs.
> Probably better to just fail the job if a reduce task goes through all TTs
> and finds that there isn't enough space.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
