hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Lowe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-2004) Priority scheduling support in Capacity scheduler
Date Mon, 20 Apr 2015 20:07:01 GMT

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

Jason Lowe commented on YARN-2004:

I'm still missing why it makes sense for queues to have different access to priorities.  Currently
priorities only have an effect within a queue, not between queues, so why would we want to
limit which priorities are running within a queue?  I'm still missing the use-case for this,
and as such it looks like additional complexity without any benefit.

bq. I have considered default priority scenario where if submitted app does not gave any priority,
then default will be taken. So chances of null here in above scenario wont happen.

Where is this occurring?  I see a lot of getDefault*Priority functions but not where they're
actually used to set the app's priority if no priority is specified during app submission.

> 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

This message was sent by Atlassian JIRA

View raw message