[jira] [Commented] (YARN-4164) Retrospect update ApplicationPriority API return type
[ https://issues.apache.org/jira/browse/YARN-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15799750#comment-15799750 ] Jian He commented on YARN-4164: --- merged the patch to 2.8 too > Retrospect update ApplicationPriority API return type > - > > Key: YARN-4164 > URL: https://issues.apache.org/jira/browse/YARN-4164 > Project: Hadoop YARN > Issue Type: Sub-task > Components: resourcemanager >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > Fix For: 2.8.0, 2.9.0, 3.0.0-alpha1 > > Attachments: 0001-YARN-4164.patch, 0002-YARN-4164.patch, > 0003-YARN-4164.patch, 0004-YARN-4164.patch > > > Currently {{ApplicationClientProtocol#updateApplicationPriority()}} API > returns empty UpdateApplicationPriorityResponse response. > But RM update priority to the cluster.max-priority if the given priority is > greater than cluster.max-priority. In this scenarios, need to intimate back > to client that updated priority rather just keeping quite where client > assumes that given priority itself is taken. > During application submission also has same scenario can happen, but I feel > when > explicitly invoke via ApplicationClientProtocol#updateApplicationPriority(), > response should have updated priority in response. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-4164) Retrospect update ApplicationPriority API return type
[ https://issues.apache.org/jira/browse/YARN-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15799668#comment-15799668 ] Junping Du commented on YARN-4164: -- This patch goes to branch-2 only instead of branch-2.8, set 2.9 as fix version. > Retrospect update ApplicationPriority API return type > - > > Key: YARN-4164 > URL: https://issues.apache.org/jira/browse/YARN-4164 > Project: Hadoop YARN > Issue Type: Sub-task > Components: resourcemanager >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > Fix For: 2.9.0, 3.0.0-alpha1 > > Attachments: 0001-YARN-4164.patch, 0002-YARN-4164.patch, > 0003-YARN-4164.patch, 0004-YARN-4164.patch > > > Currently {{ApplicationClientProtocol#updateApplicationPriority()}} API > returns empty UpdateApplicationPriorityResponse response. > But RM update priority to the cluster.max-priority if the given priority is > greater than cluster.max-priority. In this scenarios, need to intimate back > to client that updated priority rather just keeping quite where client > assumes that given priority itself is taken. > During application submission also has same scenario can happen, but I feel > when > explicitly invoke via ApplicationClientProtocol#updateApplicationPriority(), > response should have updated priority in response. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
[jira] [Commented] (YARN-4164) Retrospect update ApplicationPriority API return type
[ https://issues.apache.org/jira/browse/YARN-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15064915#comment-15064915 ] Hudson commented on YARN-4164: -- SUCCESS: Integrated in Hadoop-trunk-Commit #8999 (See [https://builds.apache.org/job/Hadoop-trunk-Commit/8999/]) YARN-4164. Changed updateApplicationPriority API to return the updated (jianhe: rev 85c24660481f33684a42a7f6d665d3117577c780) * hadoop-yarn-project/hadoop-yarn/hadoop-yarn-client/src/main/java/org/apache/hadoop/yarn/client/api/YarnClient.java * hadoop-yarn-project/hadoop-yarn/hadoop-yarn-client/src/main/java/org/apache/hadoop/yarn/client/cli/ApplicationCLI.java * hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/test/java/org/apache/hadoop/yarn/server/resourcemanager/TestClientRMService.java * hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/ClientRMService.java * hadoop-yarn-project/hadoop-yarn/hadoop-yarn-client/src/main/java/org/apache/hadoop/yarn/client/api/impl/YarnClientImpl.java * hadoop-yarn-project/hadoop-yarn/hadoop-yarn-api/src/main/proto/yarn_service_protos.proto * hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-jobclient/src/main/java/org/apache/hadoop/mapred/ResourceMgrDelegate.java * hadoop-yarn-project/CHANGES.txt * hadoop-yarn-project/hadoop-yarn/hadoop-yarn-api/src/main/java/org/apache/hadoop/yarn/api/protocolrecords/UpdateApplicationPriorityResponse.java * hadoop-yarn-project/hadoop-yarn/hadoop-yarn-common/src/main/java/org/apache/hadoop/yarn/api/protocolrecords/impl/pb/UpdateApplicationPriorityResponsePBImpl.java > Retrospect update ApplicationPriority API return type > - > > Key: YARN-4164 > URL: https://issues.apache.org/jira/browse/YARN-4164 > Project: Hadoop YARN > Issue Type: Sub-task > Components: resourcemanager >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > Fix For: 2.8.0 > > Attachments: 0001-YARN-4164.patch, 0002-YARN-4164.patch, > 0003-YARN-4164.patch, 0004-YARN-4164.patch > > > Currently {{ApplicationClientProtocol#updateApplicationPriority()}} API > returns empty UpdateApplicationPriorityResponse response. > But RM update priority to the cluster.max-priority if the given priority is > greater than cluster.max-priority. In this scenarios, need to intimate back > to client that updated priority rather just keeping quite where client > assumes that given priority itself is taken. > During application submission also has same scenario can happen, but I feel > when > explicitly invoke via ApplicationClientProtocol#updateApplicationPriority(), > response should have updated priority in response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YARN-4164) Retrospect update ApplicationPriority API return type
[ https://issues.apache.org/jira/browse/YARN-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15064854#comment-15064854 ] Jian He commented on YARN-4164: --- lgtm, +1 > Retrospect update ApplicationPriority API return type > - > > Key: YARN-4164 > URL: https://issues.apache.org/jira/browse/YARN-4164 > Project: Hadoop YARN > Issue Type: Sub-task > Components: resourcemanager >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > Attachments: 0001-YARN-4164.patch, 0002-YARN-4164.patch, > 0003-YARN-4164.patch, 0004-YARN-4164.patch > > > Currently {{ApplicationClientProtocol#updateApplicationPriority()}} API > returns empty UpdateApplicationPriorityResponse response. > But RM update priority to the cluster.max-priority if the given priority is > greater than cluster.max-priority. In this scenarios, need to intimate back > to client that updated priority rather just keeping quite where client > assumes that given priority itself is taken. > During application submission also has same scenario can happen, but I feel > when > explicitly invoke via ApplicationClientProtocol#updateApplicationPriority(), > response should have updated priority in response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YARN-4164) Retrospect update ApplicationPriority API return type
[ https://issues.apache.org/jira/browse/YARN-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15065162#comment-15065162 ] Rohith Sharma K S commented on YARN-4164: - Thanks [~jianhe] for review and committing patch > Retrospect update ApplicationPriority API return type > - > > Key: YARN-4164 > URL: https://issues.apache.org/jira/browse/YARN-4164 > Project: Hadoop YARN > Issue Type: Sub-task > Components: resourcemanager >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > Fix For: 2.8.0 > > Attachments: 0001-YARN-4164.patch, 0002-YARN-4164.patch, > 0003-YARN-4164.patch, 0004-YARN-4164.patch > > > Currently {{ApplicationClientProtocol#updateApplicationPriority()}} API > returns empty UpdateApplicationPriorityResponse response. > But RM update priority to the cluster.max-priority if the given priority is > greater than cluster.max-priority. In this scenarios, need to intimate back > to client that updated priority rather just keeping quite where client > assumes that given priority itself is taken. > During application submission also has same scenario can happen, but I feel > when > explicitly invoke via ApplicationClientProtocol#updateApplicationPriority(), > response should have updated priority in response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YARN-4164) Retrospect update ApplicationPriority API return type
[ https://issues.apache.org/jira/browse/YARN-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15063518#comment-15063518 ] Rohith Sharma K S commented on YARN-4164: - Looking into the HadoopQA result, bq. -1 cc 16m 49s root-jdk1.8.0_66 with JDK v1.8.0_66 generated 2 new issues (was 16, now 16). Not caused by this patch bq. -1 javac 25m 36s root-jdk1.7.0_91 with JDK v1.7.0_91 generated 1 new issues (was 723, now 723). Not caused by this patch And test failures are not related this patch. YARN side test case failure JIRA's are tracked by umbrella jira YARN-4478 MapReduce test case failure are tracked by MAPREDUCE-6580 and MAPREDUCE-6579 > Retrospect update ApplicationPriority API return type > - > > Key: YARN-4164 > URL: https://issues.apache.org/jira/browse/YARN-4164 > Project: Hadoop YARN > Issue Type: Sub-task > Components: resourcemanager >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > Attachments: 0001-YARN-4164.patch, 0002-YARN-4164.patch, > 0003-YARN-4164.patch, 0004-YARN-4164.patch > > > Currently {{ApplicationClientProtocol#updateApplicationPriority()}} API > returns empty UpdateApplicationPriorityResponse response. > But RM update priority to the cluster.max-priority if the given priority is > greater than cluster.max-priority. In this scenarios, need to intimate back > to client that updated priority rather just keeping quite where client > assumes that given priority itself is taken. > During application submission also has same scenario can happen, but I feel > when > explicitly invoke via ApplicationClientProtocol#updateApplicationPriority(), > response should have updated priority in response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YARN-4164) Retrospect update ApplicationPriority API return type
[ https://issues.apache.org/jira/browse/YARN-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15061477#comment-15061477 ] Sunil G commented on YARN-4164: --- Thanks [~rohithsharma] for updating the patch. Looks good. [~jianhe], could you pls help to take a look also. > Retrospect update ApplicationPriority API return type > - > > Key: YARN-4164 > URL: https://issues.apache.org/jira/browse/YARN-4164 > Project: Hadoop YARN > Issue Type: Sub-task > Components: resourcemanager >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > Attachments: 0001-YARN-4164.patch, 0002-YARN-4164.patch, > 0003-YARN-4164.patch, 0004-YARN-4164.patch > > > Currently {{ApplicationClientProtocol#updateApplicationPriority()}} API > returns empty UpdateApplicationPriorityResponse response. > But RM update priority to the cluster.max-priority if the given priority is > greater than cluster.max-priority. In this scenarios, need to intimate back > to client that updated priority rather just keeping quite where client > assumes that given priority itself is taken. > During application submission also has same scenario can happen, but I feel > when > explicitly invoke via ApplicationClientProtocol#updateApplicationPriority(), > response should have updated priority in response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YARN-4164) Retrospect update ApplicationPriority API return type
[ https://issues.apache.org/jira/browse/YARN-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15058457#comment-15058457 ] Hadoop QA commented on YARN-4164: - | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s {color} | {color:blue} Docker mode activated. {color} | | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s {color} | {color:green} The patch does not contain any @author tags. {color} | | {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 0s {color} | {color:green} The patch appears to include 1 new or modified test files. {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m 24s {color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m 5s {color} | {color:green} trunk passed with JDK v1.8.0_66 {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m 53s {color} | {color:green} trunk passed with JDK v1.7.0_91 {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 0s {color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 2m 31s {color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m 7s {color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m 51s {color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 55s {color} | {color:green} trunk passed with JDK v1.8.0_66 {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 4m 13s {color} | {color:green} trunk passed with JDK v1.7.0_91 {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m 18s {color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m 54s {color} | {color:green} the patch passed with JDK v1.8.0_66 {color} | | {color:red}-1{color} | {color:red} cc {color} | {color:red} 16m 49s {color} | {color:red} root-jdk1.8.0_66 with JDK v1.8.0_66 generated 2 new issues (was 16, now 16). {color} | | {color:green}+1{color} | {color:green} cc {color} | {color:green} 7m 54s {color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 7m 54s {color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m 46s {color} | {color:green} the patch passed with JDK v1.7.0_91 {color} | | {color:green}+1{color} | {color:green} cc {color} | {color:green} 8m 46s {color} | {color:green} the patch passed {color} | | {color:red}-1{color} | {color:red} javac {color} | {color:red} 25m 36s {color} | {color:red} root-jdk1.7.0_91 with JDK v1.7.0_91 generated 1 new issues (was 723, now 723). {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 8m 46s {color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 57s {color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 2m 30s {color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m 7s {color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s {color} | {color:green} Patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m 35s {color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 53s {color} | {color:green} the patch passed with JDK v1.8.0_66 {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 4m 14s {color} | {color:green} the patch passed with JDK v1.7.0_91 {color} | | {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 23s {color} | {color:green} hadoop-yarn-api in the patch passed with JDK v1.8.0_66. {color} | | {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 51s {color} | {color:green} hadoop-yarn-common in the patch passed with JDK v1.8.0_66. {color} | | {color:red}-1{color} | {color:red} unit {color} | {color:red} 59m 2s {color} | {color:red} hadoop-yarn-server-resourcemanager in the patch failed with JDK v1.8.0_66. {color} | | {color:red}-1{color} | {color:red} unit {color} | {color:red} 49m 21s {color} | {color:red} hadoop-yarn-client in the patch failed with JDK v1.8.0_66.
[jira] [Commented] (YARN-4164) Retrospect update ApplicationPriority API return type
[ https://issues.apache.org/jira/browse/YARN-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15057564#comment-15057564 ] Rohith Sharma K S commented on YARN-4164: - Updated the patch changing sysout message. > Retrospect update ApplicationPriority API return type > - > > Key: YARN-4164 > URL: https://issues.apache.org/jira/browse/YARN-4164 > Project: Hadoop YARN > Issue Type: Sub-task > Components: resourcemanager >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > Attachments: 0001-YARN-4164.patch, 0002-YARN-4164.patch, > 0003-YARN-4164.patch, 0004-YARN-4164.patch > > > Currently {{ApplicationClientProtocol#updateApplicationPriority()}} API > returns empty UpdateApplicationPriorityResponse response. > But RM update priority to the cluster.max-priority if the given priority is > greater than cluster.max-priority. In this scenarios, need to intimate back > to client that updated priority rather just keeping quite where client > assumes that given priority itself is taken. > During application submission also has same scenario can happen, but I feel > when > explicitly invoke via ApplicationClientProtocol#updateApplicationPriority(), > response should have updated priority in response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YARN-4164) Retrospect update ApplicationPriority API return type
[ https://issues.apache.org/jira/browse/YARN-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15035302#comment-15035302 ] Rohith Sharma K S commented on YARN-4164: - I think just log message update with clarity should be fine. I will update the patch with log message change. > Retrospect update ApplicationPriority API return type > - > > Key: YARN-4164 > URL: https://issues.apache.org/jira/browse/YARN-4164 > Project: Hadoop YARN > Issue Type: Sub-task > Components: resourcemanager >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > Attachments: 0001-YARN-4164.patch, 0002-YARN-4164.patch, > 0003-YARN-4164.patch > > > Currently {{ApplicationClientProtocol#updateApplicationPriority()}} API > returns empty UpdateApplicationPriorityResponse response. > But RM update priority to the cluster.max-priority if the given priority is > greater than cluster.max-priority. In this scenarios, need to intimate back > to client that updated priority rather just keeping quite where client > assumes that given priority itself is taken. > During application submission also has same scenario can happen, but I feel > when > explicitly invoke via ApplicationClientProtocol#updateApplicationPriority(), > response should have updated priority in response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YARN-4164) Retrospect update ApplicationPriority API return type
[ https://issues.apache.org/jira/browse/YARN-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15035274#comment-15035274 ] Sunil G commented on YARN-4164: --- Thanks [~rohithsharma] for updating the patch. {code} Priority updateApplicationPriority = client.updateApplicationPriority(appId, newAppPriority); if (newAppPriority.equals(updateApplicationPriority)) { sysout.println("Successfully updated the application " + applicationId + " with priority '" + priority + "'"); } else { sysout.println("Updated the application " + applicationId + " to cluster max priority '" + updateApplicationPriority + "'"); } {code} There is another corner case here when App is in its FINAL states. In that case, scheduler will not update the priority and last set priority is now returned. So this CLI handling will fall into else case and will print that {{"Updated the application to cluster max priority"}} which looks incorrect. One possibility is that, we can look into cluster max priority here to print correct message. I am not very interested in banging RM again with a remote request to get cluster priority, so may be we can get cluster max priority also in response. Again this seems more information in response. OR simply we can print the message in else case as a general message which is common for both cases. Thoughts? > Retrospect update ApplicationPriority API return type > - > > Key: YARN-4164 > URL: https://issues.apache.org/jira/browse/YARN-4164 > Project: Hadoop YARN > Issue Type: Sub-task > Components: resourcemanager >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > Attachments: 0001-YARN-4164.patch, 0002-YARN-4164.patch, > 0003-YARN-4164.patch > > > Currently {{ApplicationClientProtocol#updateApplicationPriority()}} API > returns empty UpdateApplicationPriorityResponse response. > But RM update priority to the cluster.max-priority if the given priority is > greater than cluster.max-priority. In this scenarios, need to intimate back > to client that updated priority rather just keeping quite where client > assumes that given priority itself is taken. > During application submission also has same scenario can happen, but I feel > when > explicitly invoke via ApplicationClientProtocol#updateApplicationPriority(), > response should have updated priority in response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YARN-4164) Retrospect update ApplicationPriority API return type
[ https://issues.apache.org/jira/browse/YARN-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15034354#comment-15034354 ] Hadoop QA commented on YARN-4164: - | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s {color} | {color:blue} Docker mode activated. {color} | | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s {color} | {color:green} The patch does not contain any @author tags. {color} | | {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 0s {color} | {color:green} The patch appears to include 1 new or modified test files. {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 9m 30s {color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 11m 6s {color} | {color:green} trunk passed with JDK v1.8.0_66 {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 10m 33s {color} | {color:green} trunk passed with JDK v1.7.0_85 {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 10s {color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 2m 56s {color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m 18s {color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m 43s {color} | {color:green} trunk passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 25s {color} | {color:green} trunk passed with JDK v1.8.0_66 {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 4m 45s {color} | {color:green} trunk passed with JDK v1.7.0_85 {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m 42s {color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 10m 28s {color} | {color:green} the patch passed with JDK v1.8.0_66 {color} | | {color:green}+1{color} | {color:green} cc {color} | {color:green} 10m 28s {color} | {color:green} the patch passed {color} | | {color:red}-1{color} | {color:red} javac {color} | {color:red} 20m 54s {color} | {color:red} root-jdk1.8.0_66 with JDK v1.8.0_66 generated 1 new issues (was 751, now 751). {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 10m 28s {color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 10m 30s {color} | {color:green} the patch passed with JDK v1.7.0_85 {color} | | {color:green}+1{color} | {color:green} cc {color} | {color:green} 10m 30s {color} | {color:green} the patch passed {color} | | {color:red}-1{color} | {color:red} javac {color} | {color:red} 31m 24s {color} | {color:red} root-jdk1.7.0_85 with JDK v1.7.0_85 generated 1 new issues (was 745, now 745). {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 10m 30s {color} | {color:green} the patch passed {color} | | {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m 11s {color} | {color:red} Patch generated 4 new checkstyle issues in root (total was 122, now 126). {color} | | {color:green}+1{color} | {color:green} mvnsite {color} | {color:green} 2m 55s {color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m 18s {color} | {color:green} the patch passed {color} | | {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s {color} | {color:red} The patch has 1 line(s) that end in whitespace. Use git apply --whitespace=fix. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 6m 37s {color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 25s {color} | {color:green} the patch passed with JDK v1.8.0_66 {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 4m 47s {color} | {color:green} the patch passed with JDK v1.7.0_85 {color} | | {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 29s {color} | {color:green} hadoop-yarn-api in the patch passed with JDK v1.8.0_66. {color} | | {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 17s {color} | {color:green} hadoop-yarn-common in the patch passed with JDK v1.8.0_66. {color} | | {color:red}-1{color} | {color:red} unit {color} | {color:red} 70m 2s {color} | {color:red} hadoop-yarn-server-resourcemanager in the patch failed with JDK v1.8.0_66. {color} | | {color:red}-1{color} | {color:red} unit
[jira] [Commented] (YARN-4164) Retrospect update ApplicationPriority API return type
[ https://issues.apache.org/jira/browse/YARN-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976047#comment-14976047 ] Rohith Sharma K S commented on YARN-4164: - bq. rather than keeping a success flag. Right, the patches returns priority only. bq. we can set this return value as "null" currently "null" is sent back to client if application is already in completing states. > Retrospect update ApplicationPriority API return type > - > > Key: YARN-4164 > URL: https://issues.apache.org/jira/browse/YARN-4164 > Project: Hadoop YARN > Issue Type: Sub-task > Components: resourcemanager >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > Attachments: 0001-YARN-4164.patch, 0002-YARN-4164.patch > > > Currently {{ApplicationClientProtocol#updateApplicationPriority()}} API > returns empty UpdateApplicationPriorityResponse response. > But RM update priority to the cluster.max-priority if the given priority is > greater than cluster.max-priority. In this scenarios, need to intimate back > to client that updated priority rather just keeping quite where client > assumes that given priority itself is taken. > During application submission also has same scenario can happen, but I feel > when > explicitly invoke via ApplicationClientProtocol#updateApplicationPriority(), > response should have updated priority in response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YARN-4164) Retrospect update ApplicationPriority API return type
[ https://issues.apache.org/jira/browse/YARN-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976049#comment-14976049 ] Rohith Sharma K S commented on YARN-4164: - Updated the patch, kindly review > Retrospect update ApplicationPriority API return type > - > > Key: YARN-4164 > URL: https://issues.apache.org/jira/browse/YARN-4164 > Project: Hadoop YARN > Issue Type: Sub-task > Components: resourcemanager >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > Attachments: 0001-YARN-4164.patch, 0002-YARN-4164.patch > > > Currently {{ApplicationClientProtocol#updateApplicationPriority()}} API > returns empty UpdateApplicationPriorityResponse response. > But RM update priority to the cluster.max-priority if the given priority is > greater than cluster.max-priority. In this scenarios, need to intimate back > to client that updated priority rather just keeping quite where client > assumes that given priority itself is taken. > During application submission also has same scenario can happen, but I feel > when > explicitly invoke via ApplicationClientProtocol#updateApplicationPriority(), > response should have updated priority in response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YARN-4164) Retrospect update ApplicationPriority API return type
[ https://issues.apache.org/jira/browse/YARN-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976656#comment-14976656 ] Naganarasimha G R commented on YARN-4164: - Also can you take a look @ checkstyle and white space ? Findbugs seems to be unrelated to this patch > Retrospect update ApplicationPriority API return type > - > > Key: YARN-4164 > URL: https://issues.apache.org/jira/browse/YARN-4164 > Project: Hadoop YARN > Issue Type: Sub-task > Components: resourcemanager >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > Attachments: 0001-YARN-4164.patch, 0002-YARN-4164.patch > > > Currently {{ApplicationClientProtocol#updateApplicationPriority()}} API > returns empty UpdateApplicationPriorityResponse response. > But RM update priority to the cluster.max-priority if the given priority is > greater than cluster.max-priority. In this scenarios, need to intimate back > to client that updated priority rather just keeping quite where client > assumes that given priority itself is taken. > During application submission also has same scenario can happen, but I feel > when > explicitly invoke via ApplicationClientProtocol#updateApplicationPriority(), > response should have updated priority in response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YARN-4164) Retrospect update ApplicationPriority API return type
[ https://issues.apache.org/jira/browse/YARN-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976557#comment-14976557 ] Hadoop QA commented on YARN-4164: - \\ \\ | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:red}-1{color} | pre-patch | 30m 20s | Pre-patch trunk has 3 extant Findbugs (version 3.0.0) warnings. | | {color:green}+1{color} | @author | 0m 0s | The patch does not contain any @author tags. | | {color:green}+1{color} | tests included | 0m 0s | The patch appears to include 1 new or modified test files. | | {color:green}+1{color} | javac | 11m 9s | There were no new javac warning messages. | | {color:green}+1{color} | javadoc | 14m 10s | There were no new javadoc warning messages. | | {color:green}+1{color} | release audit | 0m 31s | The applied patch does not increase the total number of release audit warnings. | | {color:red}-1{color} | checkstyle | 3m 34s | The applied patch generated 1 new checkstyle issues (total was 2, now 3). | | {color:red}-1{color} | whitespace | 0m 1s | The patch has 2 line(s) that end in whitespace. Use git apply --whitespace=fix. | | {color:green}+1{color} | install | 2m 1s | mvn install still works. | | {color:green}+1{color} | eclipse:eclipse | 0m 48s | The patch built with eclipse:eclipse. | | {color:green}+1{color} | findbugs | 8m 58s | The patch does not introduce any new Findbugs (version 3.0.0) warnings. | | {color:red}-1{color} | mapreduce tests | 147m 4s | Tests failed in hadoop-mapreduce-client-jobclient. | | {color:green}+1{color} | yarn tests | 0m 39s | Tests passed in hadoop-yarn-api. | | {color:red}-1{color} | yarn tests | 7m 36s | Tests failed in hadoop-yarn-client. | | {color:green}+1{color} | yarn tests | 2m 37s | Tests passed in hadoop-yarn-common. | | {color:green}+1{color} | yarn tests | 66m 9s | Tests passed in hadoop-yarn-server-resourcemanager. | | | | 296m 31s | | \\ \\ || Reason || Tests || | Failed unit tests | hadoop.mapreduce.v2.TestMRJobsWithProfiler | | | hadoop.mapred.TestMiniMRClientCluster | | | hadoop.mapreduce.v2.TestMRJobs | | | hadoop.mapreduce.v2.TestNonExistentJob | | | hadoop.mapreduce.v2.TestUberAM | | | hadoop.mapreduce.v2.TestMRJobsWithHistoryService | | | hadoop.yarn.client.api.impl.TestYarnClient | | Timed out tests | org.apache.hadoop.mapreduce.TestLargeSort | | | org.apache.hadoop.mapreduce.lib.output.TestJobOutputCommitter | \\ \\ || Subsystem || Report/Notes || | Patch URL | http://issues.apache.org/jira/secure/attachment/12768938/0002-YARN-4164.patch | | Optional Tests | javadoc javac unit findbugs checkstyle | | git revision | trunk / 96677be | | Pre-patch Findbugs warnings | https://builds.apache.org/job/PreCommit-YARN-Build/9587/artifact/patchprocess/trunkFindbugsWarningshadoop-yarn-common.html | | checkstyle | https://builds.apache.org/job/PreCommit-YARN-Build/9587/artifact/patchprocess/diffcheckstylehadoop-yarn-api.txt | | whitespace | https://builds.apache.org/job/PreCommit-YARN-Build/9587/artifact/patchprocess/whitespace.txt | | hadoop-mapreduce-client-jobclient test log | https://builds.apache.org/job/PreCommit-YARN-Build/9587/artifact/patchprocess/testrun_hadoop-mapreduce-client-jobclient.txt | | hadoop-yarn-api test log | https://builds.apache.org/job/PreCommit-YARN-Build/9587/artifact/patchprocess/testrun_hadoop-yarn-api.txt | | hadoop-yarn-client test log | https://builds.apache.org/job/PreCommit-YARN-Build/9587/artifact/patchprocess/testrun_hadoop-yarn-client.txt | | hadoop-yarn-common test log | https://builds.apache.org/job/PreCommit-YARN-Build/9587/artifact/patchprocess/testrun_hadoop-yarn-common.txt | | hadoop-yarn-server-resourcemanager test log | https://builds.apache.org/job/PreCommit-YARN-Build/9587/artifact/patchprocess/testrun_hadoop-yarn-server-resourcemanager.txt | | Test Results | https://builds.apache.org/job/PreCommit-YARN-Build/9587/testReport/ | | Java | 1.7.0_55 | | uname | Linux asf907.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux | | Console output | https://builds.apache.org/job/PreCommit-YARN-Build/9587/console | This message was automatically generated. > Retrospect update ApplicationPriority API return type > - > > Key: YARN-4164 > URL: https://issues.apache.org/jira/browse/YARN-4164 > Project: Hadoop YARN > Issue Type: Sub-task > Components: resourcemanager >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > Attachments: 0001-YARN-4164.patch, 0002-YARN-4164.patch > > > Currently {{ApplicationClientProtocol#updateApplicationPriority()}} API > returns empty UpdateApplicationPriorityResponse response. > But RM update priority to the cluster.max-priority
[jira] [Commented] (YARN-4164) Retrospect update ApplicationPriority API return type
[ https://issues.apache.org/jira/browse/YARN-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14976653#comment-14976653 ] Naganarasimha G R commented on YARN-4164: - Thanks for the patch [~rohithsharma], Yes as you mentioned, as per the patch priority will be returned as null if the app is in COMPLETED_APP_STATES, but IMHO i would not like to return null as it might lead to NPE in the client side if not properly handled, how about just returning the app's priority itself. If required to show proper logs then additional msg can be sent as part of response. The behavior what i have mentioned is also what It is currently in the REST side too. Thoughts? If you agree to my comment i think we can to do some correction in the REST side too as we are makiyng use of {{rm.getClientRMService()}} i.e. return the priority from the UpdateApplicationPriorityResponse. > Retrospect update ApplicationPriority API return type > - > > Key: YARN-4164 > URL: https://issues.apache.org/jira/browse/YARN-4164 > Project: Hadoop YARN > Issue Type: Sub-task > Components: resourcemanager >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > Attachments: 0001-YARN-4164.patch, 0002-YARN-4164.patch > > > Currently {{ApplicationClientProtocol#updateApplicationPriority()}} API > returns empty UpdateApplicationPriorityResponse response. > But RM update priority to the cluster.max-priority if the given priority is > greater than cluster.max-priority. In this scenarios, need to intimate back > to client that updated priority rather just keeping quite where client > assumes that given priority itself is taken. > During application submission also has same scenario can happen, but I feel > when > explicitly invoke via ApplicationClientProtocol#updateApplicationPriority(), > response should have updated priority in response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YARN-4164) Retrospect update ApplicationPriority API return type
[ https://issues.apache.org/jira/browse/YARN-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14965001#comment-14965001 ] Sunil G commented on YARN-4164: --- Hi [~rohithsharma] Thanks for updating patch. I have one suggestion here, {{UpdateApplicationPriorityResponse}} can now report back the updated priority. But user wont understand what exactly is this, as the name suggests only priority. So it can be more like {{succefullyUpdatedPriority}}, rather than keeping a success flag. Also when we skip priority update like in cases mentioned in YARN-4141, we can set this return value as "null" or ""n/a", to indicate operation has not done. Thoughts? > Retrospect update ApplicationPriority API return type > - > > Key: YARN-4164 > URL: https://issues.apache.org/jira/browse/YARN-4164 > Project: Hadoop YARN > Issue Type: Sub-task > Components: resourcemanager >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > Attachments: 0001-YARN-4164.patch > > > Currently {{ApplicationClientProtocol#updateApplicationPriority()}} API > returns empty UpdateApplicationPriorityResponse response. > But RM update priority to the cluster.max-priority if the given priority is > greater than cluster.max-priority. In this scenarios, need to intimate back > to client that updated priority rather just keeping quite where client > assumes that given priority itself is taken. > During application submission also has same scenario can happen, but I feel > when > explicitly invoke via ApplicationClientProtocol#updateApplicationPriority(), > response should have updated priority in response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YARN-4164) Retrospect update ApplicationPriority API return type
[ https://issues.apache.org/jira/browse/YARN-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14963396#comment-14963396 ] Hadoop QA commented on YARN-4164: - \\ \\ | (x) *{color:red}-1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:red}-1{color} | pre-patch | 21m 10s | Pre-patch trunk has 3 extant Findbugs (version 3.0.0) warnings. | | {color:green}+1{color} | @author | 0m 0s | The patch does not contain any @author tags. | | {color:green}+1{color} | tests included | 0m 0s | The patch appears to include 1 new or modified test files. | | {color:green}+1{color} | javac | 7m 51s | There were no new javac warning messages. | | {color:green}+1{color} | javadoc | 10m 19s | There were no new javadoc warning messages. | | {color:green}+1{color} | release audit | 0m 23s | The applied patch does not increase the total number of release audit warnings. | | {color:red}-1{color} | checkstyle | 2m 34s | The applied patch generated 1 new checkstyle issues (total was 2, now 3). | | {color:red}-1{color} | whitespace | 0m 2s | The patch has 2 line(s) that end in whitespace. Use git apply --whitespace=fix. | | {color:green}+1{color} | install | 1m 34s | mvn install still works. | | {color:green}+1{color} | eclipse:eclipse | 0m 33s | The patch built with eclipse:eclipse. | | {color:green}+1{color} | findbugs | 6m 21s | The patch does not introduce any new Findbugs (version 3.0.0) warnings. | | {color:red}-1{color} | mapreduce tests | 104m 23s | Tests failed in hadoop-mapreduce-client-jobclient. | | {color:green}+1{color} | yarn tests | 0m 30s | Tests passed in hadoop-yarn-api. | | {color:green}+1{color} | yarn tests | 7m 7s | Tests passed in hadoop-yarn-client. | | {color:green}+1{color} | yarn tests | 2m 7s | Tests passed in hadoop-yarn-common. | | {color:red}-1{color} | yarn tests | 61m 55s | Tests failed in hadoop-yarn-server-resourcemanager. | | | | 227m 29s | | \\ \\ || Reason || Tests || | Failed unit tests | hadoop.mapred.TestNetworkedJob | | | hadoop.yarn.server.resourcemanager.scheduler.fair.TestFairSchedulerQueueACLs | | | hadoop.yarn.server.resourcemanager.scheduler.fair.TestSchedulingUpdate | | Timed out tests | org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.TestFairSchedulerFairShare | \\ \\ || Subsystem || Report/Notes || | Patch URL | http://issues.apache.org/jira/secure/attachment/12767339/0001-YARN-4164.patch | | Optional Tests | javadoc javac unit findbugs checkstyle | | git revision | trunk / 7f0e1eb | | Pre-patch Findbugs warnings | https://builds.apache.org/job/PreCommit-YARN-Build/9476/artifact/patchprocess/trunkFindbugsWarningshadoop-yarn-common.html | | checkstyle | https://builds.apache.org/job/PreCommit-YARN-Build/9476/artifact/patchprocess/diffcheckstylehadoop-yarn-api.txt | | whitespace | https://builds.apache.org/job/PreCommit-YARN-Build/9476/artifact/patchprocess/whitespace.txt | | hadoop-mapreduce-client-jobclient test log | https://builds.apache.org/job/PreCommit-YARN-Build/9476/artifact/patchprocess/testrun_hadoop-mapreduce-client-jobclient.txt | | hadoop-yarn-api test log | https://builds.apache.org/job/PreCommit-YARN-Build/9476/artifact/patchprocess/testrun_hadoop-yarn-api.txt | | hadoop-yarn-client test log | https://builds.apache.org/job/PreCommit-YARN-Build/9476/artifact/patchprocess/testrun_hadoop-yarn-client.txt | | hadoop-yarn-common test log | https://builds.apache.org/job/PreCommit-YARN-Build/9476/artifact/patchprocess/testrun_hadoop-yarn-common.txt | | hadoop-yarn-server-resourcemanager test log | https://builds.apache.org/job/PreCommit-YARN-Build/9476/artifact/patchprocess/testrun_hadoop-yarn-server-resourcemanager.txt | | Test Results | https://builds.apache.org/job/PreCommit-YARN-Build/9476/testReport/ | | Java | 1.7.0_55 | | uname | Linux asf905.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux | | Console output | https://builds.apache.org/job/PreCommit-YARN-Build/9476/console | This message was automatically generated. > Retrospect update ApplicationPriority API return type > - > > Key: YARN-4164 > URL: https://issues.apache.org/jira/browse/YARN-4164 > Project: Hadoop YARN > Issue Type: Sub-task > Components: resourcemanager >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > Attachments: 0001-YARN-4164.patch > > > Currently {{ApplicationClientProtocol#updateApplicationPriority()}} API > returns empty UpdateApplicationPriorityResponse response. > But RM update priority to the cluster.max-priority if the given priority is > greater than cluster.max-priority. In this scenarios, need to intimate back > to client that updated priority rather just keeping quite
[jira] [Commented] (YARN-4164) Retrospect update ApplicationPriority API return type
[ https://issues.apache.org/jira/browse/YARN-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14746952#comment-14746952 ] Sunil G commented on YARN-4164: --- Hi [~rohithsharma] Thanks for raising this. To an extent I also feel that this is fine. >From client side, if we want to verify the change immediately after calling >{{updateApplicationPriority}}, we can avoid an RPC call. (as scheduler is >capable of doing max-cap with max-cluster-priority, its good to respond back >with what we changed). This is a clear advantage. However reporting back the changed value is not much conventional from what I see n hadoop apis much. But if it adds value, I think its ok. Looping [~jianhe]. > Retrospect update ApplicationPriority API return type > - > > Key: YARN-4164 > URL: https://issues.apache.org/jira/browse/YARN-4164 > Project: Hadoop YARN > Issue Type: Sub-task > Components: resourcemanager >Reporter: Rohith Sharma K S >Assignee: Rohith Sharma K S > > Currently {{ApplicationClientProtocol#updateApplicationPriority()}} API > returns empty UpdateApplicationPriorityResponse response. > But RM update priority to the cluster.max-priority if the given priority is > greater than cluster.max-priority. In this scenarios, need to intimate back > to client that updated priority rather just keeping quite where client > assumes that given priority itself is taken. > During application submission also has same scenario can happen, but I feel > when > explicitly invoke via ApplicationClientProtocol#updateApplicationPriority(), > response should have updated priority in response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (YARN-4164) Retrospect update ApplicationPriority API return type
[ https://issues.apache.org/jira/browse/YARN-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14746921#comment-14746921 ] Rohith Sharma K S commented on YARN-4164: - The API {{public void updateApplicationPriority(Priority newPriority, ApplicationId applicationId) throws YarnException;}} should return Priority instead of void return type. > Retrospect update ApplicationPriority API return type > - > > Key: YARN-4164 > URL: https://issues.apache.org/jira/browse/YARN-4164 > Project: Hadoop YARN > Issue Type: Sub-task > Components: resourcemanager >Reporter: Rohith Sharma K S > > Currently {{ApplicationClientProtocol#updateApplicationPriority()}} API > returns empty UpdateApplicationPriorityResponse response. > But RM update priority to the cluster.max-priority if the given priority is > greater than cluster.max-priority. In this scenarios, need to intimate back > to client that updated priority rather just keeping quite where client > assumes that given priority itself is taken. > During application submission also has same scenario can happen, but I feel > when > explicitly invoke via ApplicationClientProtocol#updateApplicationPriority(), > response should have updated priority in response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)