[ 
https://issues.apache.org/jira/browse/MAPREDUCE-6529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14987366#comment-14987366
 ] 

Steve Loughran commented on MAPREDUCE-6529:
-------------------------------------------

It's really antisocial to discard unwanted containers, because if your app runs 
in a queue with pre-emption allowed, other people's work gets killed so you get 
those containers —containers you just discard.

labelling is how different machine capabilities should be marked up (e.g. GPU, 
faster-cpu). This is how we do it in other YARN apps. What's needed here is the 
ability to include (potentially different) labels in the requests for different 
phases of the work. (e.g mappers anywhere, but reducers run on 
"production-reducer" nodes only)


> AppMaster will not retry to request resource if AppMaster happens to decide 
> to not use the resource
> ---------------------------------------------------------------------------------------------------
>
>                 Key: MAPREDUCE-6529
>                 URL: https://issues.apache.org/jira/browse/MAPREDUCE-6529
>             Project: Hadoop Map/Reduce
>          Issue Type: Improvement
>          Components: mr-am
>    Affects Versions: 2.6.0
>            Reporter: Wei Chen
>
> I am viewing code in RMContainerAllocator.java.   I want to do some 
> improvement  so that the AppMaster could give up some containers that may not 
> be optimal  when it receives new assigned containers.  But I found that if 
> AppMaster give up the containers, it will not retry to request the resource 
> again.
> int RMContainerRequestor.java, Set<ResourceRequest> ask  is used to ask 
> resource from ResourceManager. I found each container could only be requested 
> once. It mean ask can be filled by addResourceRequestToAsk(ResourceRequest 
> remoteRequest[]), but it can only added for once for each container. If we 
> give up one assigned container, It will never request again



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to