Sunil G commented on YARN-2004:

Thank you [~jlowe]
@@ -327,6 +328,29 @@ private RMAppImpl createAndPopulateNewRMApp(
     ApplicationId applicationId = submissionContext.getApplicationId();
     ResourceRequest amReq =
         validateAndCreateResourceRequest(submissionContext, isRecovery);
+    Priority appPriority = submissionContext.getPriority();
+    if (null != appPriority) {
+      try {
+        rmContext.getScheduler().authenticateApplicationPriority(
+            submissionContext.getPriority(), user,
+            submissionContext.getQueue(), applicationId);
+      } catch (IOException e) {
+        throw RPCUtil.getRemoteException(e.getMessage());
+      }
+    } else {
+      // Get the default priority from Queue and set to Application
+      try {
+        appPriority = rmContext.getScheduler()
+      } catch (IOException e) {

Above code snippet is from YARN-2003 which is handing changes in RM and Events 
for priority. When an app is submitted w/o priority, we would like to fill in 
with default priority from queue.

bq.why would we want to limit which priorities are running within a queue?
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.

[~leftnoteasy] Do you mean a global max priority which can help to limit the 
number associated with a priority ?

bq. we just cap it by max-priority-limit instead of throw exception? 
Yes. I will update this part as against throwing exception.

> 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

Reply via email to