hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sunil G (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-6280) Add a query parameter in ResourceManager Cluster Applications REST API to control whether or not returns ResourceRequest
Date Tue, 09 May 2017 09:53:04 GMT

    [ https://issues.apache.org/jira/browse/YARN-6280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16002402#comment-16002402

Sunil G commented on YARN-6280:

Thanks [~cltlfcjin]

Few comments

#  {{DeSelectQuery.java}} could be inside *webapp* package itself. I do not think its a common
api class yet.
# {{DeSelectQuery}}. I think *setDeSelect* need not have to be invoked from constructor. This
method cud throw some exceptions, so it may be better as a separate public method which could
be invoked from RMWebService api.
# Java doc for {{DeSelectParam}} could be more descriptive and could explain abt possible
params which are supported now.
# In {{setDeSelect}} exception block, currently LOG.info is used. It could be warn.
# in below code
43	    if (deSelect != null && !deSelect.isEmpty()) {
44	      for (String query : deSelect) {
45	        if (query != null && !query.trim().isEmpty()) {
I think {{query}} wont be null here. u may skip that. in first if condition, i think {{deSelect.isEmpty()}}
could be avoided. for loop will skip if {{deSelect}} is empty. What you need is just check
for null against deSelect. Its better a simple null check could be added and return directly.

# Currently you have mentioned {{resourceRequests}} could be set in {{deSelect}}. Thinking
out loud, is it more error prone or tougher for user to give exact *resourceRequests*. Could
we name it *resource-requests* ? thoughts

> Add a query parameter in ResourceManager Cluster Applications REST API to control whether
or not returns ResourceRequest
> ------------------------------------------------------------------------------------------------------------------------
>                 Key: YARN-6280
>                 URL: https://issues.apache.org/jira/browse/YARN-6280
>             Project: Hadoop YARN
>          Issue Type: Improvement
>          Components: resourcemanager, restapi
>    Affects Versions: 2.7.3
>            Reporter: Lantao Jin
>            Assignee: Lantao Jin
>         Attachments: YARN-6280.001.patch, YARN-6280.002.patch, YARN-6280.003.patch, YARN-6280.004.patch,
YARN-6280.005.patch, YARN-6280.006.patch, YARN-6280.007.patch, YARN-6280.008.patch
> Begin from v2.7, the ResourceManager Cluster Applications REST API returns   ResourceRequest
list. It's a very large construction in AppInfo.
> As a test, we use below URI to query only 2 results:
> http://<rm http address:port>/ws/v1/cluster/apps?states=running,accepted&limit=2
> The results are very different:
> ||Hadoop version|Total Character|Total Word|Total Lines|Size||
> |2.4.1|1192|	42|	42|	1.2 KB|
> |2.7.1|1222179|	48740|	48735|	1.21 MB|
> Most RESTful API requesters don't know about this after upgraded and their old queries
may cause ResourceManager more GC consuming and slower. Even if they know this but have no
idea to reduce the impact of ResourceManager except slow down their query frequency.
> The patch adding a query parameter "showResourceRequests" to help requesters who don't
need this information to reduce the overhead. In consideration of compatibility of interface,
the default value is true if they don't set the parameter, so the behaviour is the same as

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org

View raw message