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

Sunil G commented on YARN-2004:
-------------------------------

Thank you [~jlowe] and [~leftnoteasy] for the input.

Yes, there are alternate ways we can achieve scenario 1. Also for scenario 2, 
YARN-2009 will help. Hence this JIRA can now currently focus on the basic 
priority addition to Schedulers.

bq.Priority is only considered if both applications have a priority that was 
set. 

If a set of priorities is loaded to RM and one is  chosen as Default priority 
for a queue, it can be any priority from lowest to highest. So All the 
applications running w/o priority will be given as this default priority. Hence 
some lower priority application will end up with lower preference than an 
application running w/o priority. 
But this is also a perception from user. If user can consider that all 
applications running w/o priority will fall to default chosen one per queue , 
then the behavior will be as expected. 
On that note, I also feel that i can consider all applications running w/o 
priority will be of Default priority. [~jlowe] Pls share your thoughts w.r.t 
the above scenario.

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