[
https://issues.apache.org/jira/browse/YARN-10871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prabhu Joseph reassigned YARN-10871:
------------------------------------
Assignee: Srinivas S T (was: Prabhu Joseph)
> Aborted AM is considered as App Failure when user sets MaxAttempts as 1
> -----------------------------------------------------------------------
>
> Key: YARN-10871
> URL: https://issues.apache.org/jira/browse/YARN-10871
> Project: Hadoop YARN
> Issue Type: Bug
> Components: RM
> Affects Versions: 3.3.1
> Reporter: Prabhu Joseph
> Assignee: Srinivas S T
> Priority: Major
>
> When an AM Container is ABORTED due to Node Decommission, the AppAttempt
> failure is not counted. But if user sets number of attempts as 1, then YARN
> considers the ABORTED AM as a failure.
> {code}
> int numberOfFailure = app.getNumFailedAppAttempts();
> if (app.maxAppAttempts == 1) {
> // If the user explicitly set the attempts to 1 then there are likely
> // correctness issues if the AM restarts for any reason.
> LOG.info("Max app attempts is 1 for " + app.applicationId
> + ", preventing further attempts.");
> numberOfFailure = app.maxAppAttempts;
> }
> {code}
> Livy sets the number of attempts as 1 since it's Rpc Server does not yet
> support multiple connections for the same registered app. But in our case AM
> is ABORTED before even the AM starts (AM was in ACAUIRED state)
> Usually users won't decommission the node where the Container is in RUNNING
> state (where the session is established). But the decommission can happen on
> nodes where the container is in ACQUIRED or ALLOCATED state.
> Will suggest to expose an config where user can decide whether to consider
> this as a failure or not.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
