hadoop-yarn-issues mailing list archives

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

    [ 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

View raw message