[ 
https://issues.apache.org/jira/browse/YARN-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)

Reply via email to