[jira] [Commented] (YARN-11079) Make an AbstractParentQueue to store common ParentQueue and ManagedParentQueue functionality

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

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

ASF GitHub Bot commented on YARN-11079:
---------------------------------------

szilard-nemeth commented on PR #5380:
URL: https://github.com/apache/hadoop/pull/5380#issuecomment-1530426310

   Hi @susheel-gupta ,
   Just took a look at your changes in this PR.
   
   I compared the old version of ParentQueue vs. AbstractParentQueue and found some differences: 
   - the private int field with name 'numApplications' was volatile, now it is changed to AtomicInteger. What is the reason of this? 
   - In the method called 'addApplication', the writelock was locked during incrementing numApplications, now I can see it removed. Do you know why this was necessary?
   - Same for method called 'removeApplication'
   
   Otherwise LGTM




> Make an AbstractParentQueue to store common ParentQueue and ManagedParentQueue functionality
> --------------------------------------------------------------------------------------------
>
>                 Key: YARN-11079
>                 URL: https://issues.apache.org/jira/browse/YARN-11079
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: capacity scheduler
>            Reporter: Benjamin Teke
>            Assignee: Susheel Gupta
>            Priority: Major
>              Labels: pull-request-available
>
> ParentQueue is an instantiable class which stores the necessary functionality of parent queues, however it is also extended by the AbstractManagedParentQueue, which is an abstract class for storing managed parent queue functionality. Since legacy AQC doesn't allow dynamic queues next to static ones, managed parent queues technically behave like leaf queues by not having any static child queues when created. This structure and behaviour is really error prone, as for example if someone is not completely aware of this and simply changes the checking order by first checking if the queue in question is a ParentQueue in a method like MappingRuleValidationContextImpl.isDynamicParent can result a completely wrong return value (as a ManagedParent is a dynamic parent, but currently it's also a ParentQueue, and ManagedParent cannot have the isEligibleForAutoQueueCreation as true, so the method will return false). 
> {code:java}
>   private boolean isDynamicParent(CSQueue queue) {
>     if (queue == null) {
>       return false;
>     }
>     if (queue instanceof ManagedParentQueue) {
>       return true;
>     }
>     if (queue instanceof ParentQueue) {
>       return ((ParentQueue)queue).isEligibleForAutoQueueCreation();
>     }
>     return false;
>   }
> {code}
> Similarly to YARN-11024 an AbstractParentQueue class should be created to completely separate the managed parents from the instantiable ParentQueue class.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org