[
https://issues.apache.org/jira/browse/YARN-7952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16399351#comment-16399351
]
Robert Kanter commented on YARN-7952:
-------------------------------------
Thanks for the updated patch. Two last things:
# Instead of throwing an Exception when the config is <= 0, which will crash
the NM, I think it would be better to log a WARN message and use the default
value.
# In the {{assertEquals}} statements, the first argument is actually the
expected value and the second is the actual value. So we need to swap the
argument order in the tests on those.
> RM should be able to recover log aggregation status after restart/fail-over
> ---------------------------------------------------------------------------
>
> Key: YARN-7952
> URL: https://issues.apache.org/jira/browse/YARN-7952
> Project: Hadoop YARN
> Issue Type: Bug
> Reporter: Xuan Gong
> Assignee: Xuan Gong
> Priority: Major
> Attachments: YARN-7952-poc.patch, YARN-7952.1.patch,
> YARN-7952.2.patch, YARN-7952.3.patch, YARN-7952.3.patch, YARN-7952.5.patch,
> YARN-7952.6.patch, YARN-7952.7.patch, YARN-7952.8.patch
>
>
> Right now, the NM would send its own log aggregation status to RM
> periodically to RM. And RM would aggregate the status for each application,
> but it will not generate the final status until a client call(from web ui or
> cli) trigger it. But RM never persists the log aggregation status. So, when
> RM restarts/fails over, the log aggregation status will become “NOT_STARTED”.
> This is confusing, maybe we should change it to “NOT_AVAILABLE” (will create
> a separate ticket for this). Anyway, we need to persist the log aggregation
> status for the future use.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
