[
https://issues.apache.org/jira/browse/YARN-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13946796#comment-13946796
]
Zhijie Shen commented on YARN-1809:
-----------------------------------
Thanks for the comments, Mayank!
bq. history protocol already have these methods so don't need to wait , as they
have dummy iplementation for that.
If you insist on putting these methods on base protocol before having a real
implementation, I'm fine about it. The only concern is the potential HA
related annotation on the methods, which may not describe the situation on the
AHS side.
bq. The motivation for context is to wrap RM and AHS application data, SO I
think having context make sense as protocol has totally different motivation
and methods as well when we add the delegation methods to it.
bq. If we add appliction context back then we need to rebase the patch
according to that.
Previously, I created ApplicationContext to uniform the data source channel for
the web pages of both RM and AHS. See my proposal on YARN-954:
https://issues.apache.org/jira/browse/YARN-954?focusedCommentId=13823209&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13823209
Now the situation is changed. I find ApplicationBaseProtocol is the better
uniformed channel to pull application data from either RM or AHS, thus
ApplicationContext is of no use. The DT related methods are exposed via
ApplicationClientProtocol and ApplicationHistoryProtocol now, and have nothing
to do with ApplicationContext.
bq. This should be=> it is a base protocol for application client and history.
The suggested description sounds not accurate. The protocol is use by both
server and client. In other words, it is used by the communication between the
client and RM or AHS.
bq. Shouldn't we add \@Idempotent to getallapplications as well?
YARN-1521 is still not done, and \@Idempotent is not added for
getallapplications. Once YARN-1521 is done, I'll verify the annotations are
fine for AHS side implementation as well or not, and rebase
ApplicationBaseProtocol accordingly.
> Synchronize RM and Generic History Service Web-UIs
> --------------------------------------------------
>
> Key: YARN-1809
> URL: https://issues.apache.org/jira/browse/YARN-1809
> Project: Hadoop YARN
> Issue Type: Bug
> Reporter: Zhijie Shen
> Assignee: Zhijie Shen
> Attachments: YARN-1809.1.patch, YARN-1809.2.patch, YARN-1809.3.patch,
> YARN-1809.4.patch, YARN-1809.5.patch, YARN-1809.5.patch, YARN-1809.6.patch
>
>
> After YARN-953, the web-UI of generic history service is provide more
> information than that of RM, the details about app attempt and container.
> It's good to provide similar web-UIs, but retrieve the data from separate
> source, i.e., RM cache and history store respectively.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
