[
https://issues.apache.org/jira/browse/YARN-7952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16390650#comment-16390650
]
Wangda Tan commented on YARN-7952:
----------------------------------
Thanks [~xgong] for update, mostly looks good, few nits:
1) ContainerManagerImpl: changes are unnecessary.
2) NMLogAggregationStatusTracker:
- trackers => maybe recoveryStatuses?
- trackers should be ConcurrentMap since it will be written under readlock.
- rollLogAggregationStatus: can be private, and the {{@Private}} is unnecessary.
> 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
>
>
> 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: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
