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 2014/07/02 05:04:28 UTC

[jira] [Commented] (YARN-2074) Preemption of AM containers shouldn't count towards AM failures

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

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

bq. Talked with Vinod offline, the big problem with this is even if we don't count AM preemption towards AM failures on RM side, MR AM itself checks the attempt id against the max-attempt count for recovery. Work around is to reset the MAX-ATTEMPT env each time launching the AM which sounds a bit hacky though.
Filed MAPREDUCE-5956 for this..

> Preemption of AM containers shouldn't count towards AM failures
> ---------------------------------------------------------------
>
>                 Key: YARN-2074
>                 URL: https://issues.apache.org/jira/browse/YARN-2074
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: resourcemanager
>            Reporter: Vinod Kumar Vavilapalli
>            Assignee: Jian He
>             Fix For: 2.5.0
>
>         Attachments: YARN-2074.1.patch, YARN-2074.2.patch, YARN-2074.3.patch, YARN-2074.4.patch, YARN-2074.5.patch, YARN-2074.6.patch, YARN-2074.6.patch, YARN-2074.7.patch, YARN-2074.7.patch, YARN-2074.8.patch
>
>
> One orthogonal concern with issues like YARN-2055 and YARN-2022 is that AM containers getting preempted shouldn't count towards AM failures and thus shouldn't eventually fail applications.
> We should explicitly handle AM container preemption/kill as a separate issue and not count it towards the limit on AM failures.



--
This message was sent by Atlassian JIRA
(v6.2#6252)