hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mayank Bansal (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-1809) Synchronize RM and Generic History Service Web-UIs
Date Tue, 25 Mar 2014 16:14:16 GMT

    [ 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.

+ * 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

View raw message