[
https://issues.apache.org/jira/browse/YARN-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16659719#comment-16659719
]
Wangda Tan commented on YARN-6167:
----------------------------------
Thanks [~billie.rinaldi],
1) Inside releaseContainers, why add following if?
{code}
} else if (amHandlesNMLoss(rmApp)) {
LOG.debug("Adding " + containerId + " to the release request cache.");
attempt.getPendingRelease().add(containerId);
}
{code}
2) Rename amHandlesNMLoss => amSkipContainerKillWhenNMLoss. To make it more
specific.
3) Why changes of RMContainerImpl required?
{code}
.addTransition(RMContainerState.RUNNING, RMContainerState.RUNNING,
RMContainerEventType.LAUNCHED)
{code}
4) Inside {{AbstractYarnScheduler}}, it invokes {{clearPendingContainerCache}}.
For our case, we may have to skip cleaning containers which come from lost NM.
I felt it makes things more complicated. Instead of handling "pendingRelease"
for such containers, can we let AM handle it once NM comes back to normal
state? AM should be notified after that.
> RM option to delegate NM loss container action to AM
> ----------------------------------------------------
>
> Key: YARN-6167
> URL: https://issues.apache.org/jira/browse/YARN-6167
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: scheduler
> Reporter: Billie Rinaldi
> Assignee: Billie Rinaldi
> Priority: Major
> Attachments: YARN-6167.01.patch
>
>
> Currently, if the RM times out an NM, the scheduler will kill all containers
> that were running on the NM. For some applications, in the event of a
> temporary NM outage, it might be better to delegate to the AM the decision
> whether to kill the containers and request new containers from the RM.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
