[
https://issues.apache.org/jira/browse/YARN-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14337577#comment-14337577
]
Vinod Kumar Vavilapalli commented on YARN-3265:
-----------------------------------------------
Pasting comments I was going to paste on YARN-3251.
ResourceUsage
- Not sure why we need to do this, can we fix this?
{code}
+ return getHeadroom(NL, Resources.none());
{code}
- 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.
ParentQueue
- Can we improve the names in setHeadroomOfChild API? It's a complicated
method.
- 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
though.
> 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
(v6.3.4#6332)
