[
https://issues.apache.org/jira/browse/YARN-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13692525#comment-13692525
]
Omkar Vinit Joshi commented on YARN-884:
----------------------------------------
Probably these two are unrelated. First if NM goes down then obviously if AM is
running on it has gone down but vis-a-versa is not true. In work preserving
environment we would like to restart/resume the AM which will not be possible
if we configure liveness interval of am = smallest of {am,nm}.. For example nm
might be facing problems to connect to RM and may just end up heart beating
with RM just before RM took the decision about starting new application
attempt, marking earlier as failed... even if AM heartbeats immediately after
that it would be waste... right??
I think we need am = larget of {am,nm}
thoughts?
> AM expiry interval should be set to smaller of {am,
> nm}.liveness-monitor.expiry-interval-ms
> -------------------------------------------------------------------------------------------
>
> Key: YARN-884
> URL: https://issues.apache.org/jira/browse/YARN-884
> Project: Hadoop YARN
> Issue Type: Improvement
> Affects Versions: 2.0.4-alpha
> Reporter: Karthik Kambatla
> Assignee: Karthik Kambatla
> Labels: configuration
>
> As the AM can't outlive the NM on which it is running, it is a good idea to
> disallow setting the am.liveness-monitor.expiry-interval-ms to a value higher
> than nm.liveness-monitor.expiry-interval-ms
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
