hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bikas Saha (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-193) Scheduler.normalizeRequest does not account for allocation requests that exceed maximumAllocation limits
Date Sun, 31 Mar 2013 22:17:15 GMT

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

Bikas Saha commented on YARN-193:
---------------------------------

This and others like it are back-incompatible but might be ok since we are still in alpha
{code}
-  public static final int DEFAULT_RM_SCHEDULER_MAXIMUM_ALLOCATION_CORES = 32;
+  public static final int DEFAULT_RM_SCHEDULER_MAXIMUM_ALLOCATION_VCORES = 32;
{code}

It should be disabled. Same for other places.
{code}
+    maximum allocation is disable.</description>
{code}

This and other places, a LOG in the catch would be good.
Also, I am not warming up to the idea of having to put a try catch around every validate.
{code}
+      // sanity check
+      try {
+        SchedulerUtils.validateResourceRequests(ask,
+            rScheduler.getMaximumResourceCapability());
+      } catch (InvalidResourceRequestException e) {
+        RPCUtil.getRemoteException(e);
+      }
{code}

Incorrect log message.
{code}
+        try {
+          SchedulerUtils.validateResourceRequest(amReq,
+              scheduler.getMaximumResourceCapability());
+        } catch (InvalidResourceRequestException e) {
+          LOG.info("RM App submission failed in normalize AM Resource Request "
+              + "for application with id " + applicationId + " : "
+              + e.getMessage());
{code}
Also, in this method, why are we throwing an exception in the inner block and catching it
in the outer block. Why is the inner try catch needed (instead of catching the exception in
the outer catch)?
On the same note, why can this validation not be done in ClientRMService just like its been
done in ApplicationMasterService? That maintains symmetry and is easier to understand/correlate.
It will also work when RMAppManager.handle() is not called synchronously from ClientRMService.

Where are we testing that normalize is being set to the next higher multiple of min but not
more than the max (for DRF case)? OR that checking against max is disabled by setting MAX
allowed to -1. I am sorry if I have missed it.

                
> Scheduler.normalizeRequest does not account for allocation requests that exceed maximumAllocation
limits 
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: YARN-193
>                 URL: https://issues.apache.org/jira/browse/YARN-193
>             Project: Hadoop YARN
>          Issue Type: Bug
>          Components: resourcemanager
>    Affects Versions: 2.0.2-alpha, 3.0.0
>            Reporter: Hitesh Shah
>            Assignee: Zhijie Shen
>         Attachments: MR-3796.1.patch, MR-3796.2.patch, MR-3796.3.patch, MR-3796.wip.patch,
YARN-193.4.patch, YARN-193.5.patch, YARN-193.6.patch, YARN-193.7.patch, YARN-193.8.patch,
YARN-193.9.patch
>
>


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message