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 

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").

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] 
 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

Reply via email to