[
https://issues.apache.org/jira/browse/YARN-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13718643#comment-13718643
]
Zhijie Shen commented on YARN-389:
----------------------------------
bq. The check that container resource > resource in the cluster is probably
less useful compared to checking the container resource > resource on the
largest machine.
Agree, and should the resource here be the remaining unused resource?
bq. I think we should reject the problematic requests at allocate call but not
when it is accepted
IMHO, should we give a second chance to the request? The resource of a cluster
is dynamic due to NM churn and container acquisition/release. A requests that
cannot be fulfilled immediately may be affordable later. Shall we allow some
time or retry quota to the request? As [~tucu00] suggested, maybe we can
accepted the request, and move it to DISCARDED if no NM can fulfill the request
before it expires.
> Infinitely assigning containers when the required resource exceeds the
> cluster's absolute capacity
> --------------------------------------------------------------------------------------------------
>
> Key: YARN-389
> URL: https://issues.apache.org/jira/browse/YARN-389
> Project: Hadoop YARN
> Issue Type: Bug
> Reporter: Zhijie Shen
> Assignee: Omkar Vinit Joshi
>
> I've run wordcount example on branch-2 and trunk. I've set
> yarn.nodemanager.resource.memory-mb to 1G and
> yarn.app.mapreduce.am.resource.mb to 1.5G. Therefore, resourcemanager is to
> assign a 2G AM container for AM. However, the nodemanager doesn't have enough
> memory to assign the container. The problem is that the assignment operation
> will be repeated infinitely, if the assignment cannot be accomplished. Logs
> follow.
--
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
