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

Wangda Tan commented on YARN-2004:
----------------------------------

Thanks [~sunilg]'s update, some comments from my side:

1) getMaxClusterLevelAppPriority should return Priority.

2) updateApplicationPriority,
I think updateApplicationPriority needs to send a message to RMApp so RMApp can 
write it to state store, once RM fails and recovers app, we should get priority 
after updating.

And I suggest to create a method to SchedulerApplication, it will set priority 
to itself and SchedulerApplicationAttempt. And could you make set priority 
doesn't acquire application synchronized lock?

3) authenticateApplicationPriority: typically, LOG.debug needs wrapped by 
LOG.isDebugEnabled...

4) dflt should be better default, dflt is not a very common abbreviation in 
code to me. :)

5) change of compareInputOrderTo is not correct to me. {{compareInputOrderTo}} 
is to compare which application submission first. I think you need to modify 
{{FifoComparator}}, and compare priority based on SchedulerApplicationAttempt's 
priority. Changes of FairComparator is needed, but I think we can postpone the 
change, since FairComparator + Fifo may be more complicated : Should we do 
priority comparison first (treat priority as "class") OR combination of them 
(treat priority as "factor").

[~jianhe]:
bq. We may just move the check into RMAppManager...
This may not work, since priority mapping happens in scheduler side. (set app's 
priority according to queue's default priority).

bq. updateApplicationPriority - I think we don’t need to add an unused API now. 
I think update app priority is an important use case, according to [~jlowe] 
comment: 
https://issues.apache.org/jira/browse/YARN-1963?focusedCommentId=14328071&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14328071.
 I suggest to keep update application priority here.

> Priority scheduling support in Capacity scheduler
> -------------------------------------------------
>
>                 Key: YARN-2004
>                 URL: https://issues.apache.org/jira/browse/YARN-2004
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: capacityscheduler
>            Reporter: Sunil G
>            Assignee: Sunil G
>         Attachments: 0001-YARN-2004.patch, 0002-YARN-2004.patch, 
> 0003-YARN-2004.patch, 0004-YARN-2004.patch, 0005-YARN-2004.patch, 
> 0006-YARN-2004.patch, 0007-YARN-2004.patch, 0008-YARN-2004.patch
>
>
> Based on the priority of the application, Capacity Scheduler should be able 
> to give preference to application while doing scheduling.
> Comparator<FiCaSchedulerApp> applicationComparator can be changed as below.   
>         
> 1.    Check for Application priority. If priority is available, then return 
> the highest priority job.
> 2.    Otherwise continue with existing logic such as App ID comparison and 
> then TimeStamp comparison.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to