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

Eric Payne commented on YARN-2004:
----------------------------------

[~sunilg], Thanks for all of the work you are doing for this important feature.

{quote}
queueA: default=low
queueB: default=medium

The type of apps which we run may vary from queueA to B. So by keeping default 
priority different for each queue will help to handle such case. Assume more 
high level apps are running in queueA often, and medium level in queueB. Making 
different default priority can help here.
{quote}

I don't know a lot about the fair scheduler, but I'm pretty sure that in the 
capacity scheduler, there is no way to make one queue a higher priority than 
another. There is no way to compare job priorities between queues. That is, you 
can't say that jobs running in queueA have a higher priority than jobs running 
in queueB. So, it only makes sense to compare priorities between jobs in the 
same queue. Am I missing something?

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