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

Sunil G commented on YARN-3098:
-------------------------------

Yes [~leftnoteasy]

I understood you point. Sometimes we can take the call to keep a clean 
interface in top level and I also understood your intention

As for the second point, 
ResourceUsage and QueueCapacities are two new classes. and It have its own 
separate locks now.
Earlier this data is protected with the parent lock alone. SO now lock order is 
LeafQueue -> ResourceUsage.

I was worried a scenario where LeafQueue and ParentQueue is invoking these 2 
new classes in opposite order, as per my review the locking order is correct. 
But when future additions happens in LeafQueue/ParentQueue/FiCaScehdulerApp 
etc, keeping correct lock order is at most priority. 
On that note, I was thinking that these 2 new locks should not complicate 
existing locks. This was I meant earlier.

> Create common QueueCapacities class in Capacity Scheduler to track 
> capacities-by-labels of queues
> -------------------------------------------------------------------------------------------------
>
>                 Key: YARN-3098
>                 URL: https://issues.apache.org/jira/browse/YARN-3098
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: capacityscheduler
>            Reporter: Wangda Tan
>            Assignee: Wangda Tan
>         Attachments: YARN-3098.1.patch, YARN-3098.2.patch, YARN-3098.3.patch, 
> YARN-3098.4.patch
>
>
> Similar to YARN-3092, after YARN-796, now queues (ParentQueue and LeafQueue) 
> need to track capacities-label (e.g. absolute-capacity, maximum-capacity, 
> absolute-capacity, absolute-maximum-capacity, etc.). It's better to have a 
> class to encapsulate these capacities to make both better 
> maintainability/readability and fine-grained locking.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to