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

Jason Lowe commented on YARN-2004:
----------------------------------

I took a closer look at the patch, and the following logic seems suspect:

{code}
+      if (a1.getApplicationPriority() != null
+          && a2.getApplicationPriority() != null
+          && !a1.getApplicationPriority().equals(a2.getApplicationPriority())) 
{
+        return a2.getApplicationPriority().compareTo(
+            a1.getApplicationPriority());
+      }
{code}

Priority is only considered if both applications have a priority that was set.  
Do we really want that behavior?  I'm thinking of the scenario where all the 
apps in the queue have no set priority then one of the apps has their priority 
set to very high or very low.  That has no net effect since all other apps 
being compared in the queue don't have a priority set.  A more intuitive 
behavior is to treat an unset priority as if the app had a default priority, so 
we aren't implicitly disabling priority checks in some scenarios.

> 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