Vinod Kumar Vavilapalli commented on YARN-3265:

Pasting comments I was going to paste on YARN-3251.

 - Not sure why we need to do this, can we fix this?
+    return getHeadroom(NL, Resources.none());
 - Should we instead call this headRoom to be something like a resourceLimit 
and make it a different object?
 - Also, instead of setting this object in the leaf-queue, the better model is 
to simply pass it down in the allocateContainer() API.

 - Can we improve the names in setHeadroomOfChild API? It's a complicated 
 - When updateClusterResource() is called, do we really need the setHeadRoom 
call() after we start passing down the API?

Testcase: Can you draw a simple tree of the queues for readability?

It's very confusing that application-headroom gives the extra room apps have, 
but the one inside LeafQueue.QueueHeadroomInfo is overall allocation possible 
(including used resources). We should fix this - not caused by your patch 

> CapacityScheduler deadlock when computing absolute max avail capacity (fix 
> for trunk/branch-2)
> ----------------------------------------------------------------------------------------------
>                 Key: YARN-3265
>                 URL: https://issues.apache.org/jira/browse/YARN-3265
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: capacityscheduler, resourcemanager
>            Reporter: Wangda Tan
>            Assignee: Wangda Tan
>            Priority: Blocker
>         Attachments: YARN-3265.1.patch
> This patch is trying to solve the same problem described in YARN-3251, but 
> this is a longer term fix for trunk and branch-2.

This message was sent by Atlassian JIRA

Reply via email to