You are viewing a plain text version of this content. The canonical link for it is here.
Posted to yarn-issues@hadoop.apache.org by "Bikas Saha (JIRA)" <ji...@apache.org> on 2013/04/01 00:17:15 UTC

[jira] [Commented] (YARN-193) Scheduler.normalizeRequest does not account for allocation requests that exceed maximumAllocation limits

    [ 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