[
https://issues.apache.org/jira/browse/YARN-1809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13946731#comment-13946731
]
Mayank Bansal commented on YARN-1809:
-------------------------------------
Thanks [~zjshen] for the patch
bq. Yes, I think it should, but I prefer to put it in ApplicationBaseProtocol
when ApplicationHistoryClientService has implemented DT related methods.
history protocol already have these methods so don't need to wait , as they
have dummy iplementation for that.
bq. ApplicationBaseProtocol and ApplicationContext are completely different
things. ApplicationBaseProtocol is the PRC interface. Previously, I thought we
should have a uniformed ApplicationContext: on the RM side, it wraps RMContext;
while on the AHS side, it wraps ApplicationHistory. However, inspired by
RMWebServices#getApps, I think the RPC interface is a better place to uniform
the way of retrieving app info, so I created ApplicationBaseProtocol. And
ApplicationContext is no longer useful.
ApplicationBaseProtocol would be the base protocol of Client and history
however application context is something different. 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. I understand the big patch is desperate for review, but I've to do that
because the patch is aiming to refactor the code to avoid duplicate web-UI code
for RM and for AHS. The two webUI should share the common code path, and then
display similarly.
I am fine with this if this is something you want to do.
{code}
<p>
+ * The protocol between clients and the <code>ResourceManager</code> or
+ * <code>ApplicationHistoryServer</code> to get information on applications,
+ * application attempts and containers.
+ * </p>
This should be=> it is a base protocol for application client and history.
Shouldn't we add @Idempotent to getallapplications as well?
If we add appliction context back then we need to rebase the patch according to
that.
> 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)
