You are viewing a plain text version of this content. The canonical link for it is here.
Posted to yarn-issues@hadoop.apache.org by "Vinod Kumar Vavilapalli (JIRA)" <ji...@apache.org> on 2016/03/18 08:50:33 UTC

[jira] [Commented] (YARN-4685) AM blacklisting result in application to get hanged

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

Vinod Kumar Vavilapalli commented on YARN-4685:
-----------------------------------------------

There are simpler cases which are busted too. For e.g, if an AM failed on a node, this node will *never* be looked again for launching this app's AM as it is within the blacklist threshold. In a busy cluster where this node continues to be the only one free for a while, we will keep on skipping the machine.

> AM blacklisting result in application to get hanged
> ---------------------------------------------------
>
>                 Key: YARN-4685
>                 URL: https://issues.apache.org/jira/browse/YARN-4685
>             Project: Hadoop YARN
>          Issue Type: Bug
>          Components: resourcemanager
>    Affects Versions: 2.8.0
>            Reporter: Rohith Sharma K S
>            Assignee: Rohith Sharma K S
>
> AM blacklist addition or removal is updated only when RMAppAttempt is scheduled i.e {{RMAppAttemptImpl#ScheduleTransition#transition}}. But once attempt is scheduled if there is any removeNode/addNode in cluster then this is not updated to {{BlackListManager#refreshNodeHostCount}}. This leads BlackListManager to operate on stale NM's count. And application is in ACCEPTED state and wait forever even if we add more nodes to cluster.
> Solution is update BlacklistManager for every {{RMAppAttemptImpl#AMContainerAllocatedTransition#transition}} call. This ensures if there is any addition/removal in nodes, this will be updated to BlacklistManager 



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