[
https://issues.apache.org/jira/browse/YARN-3137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305758#comment-14305758
]
Jason Lowe commented on YARN-3137:
----------------------------------
This can be aggravated by the ClientRMService.getQueueInfo implementation which
will call checkAccess for every application returned. That could potentially
be every application the RM knows about, which can often be over 10,000
attempts to grab the scheduler lock.
> CapacityScheduler.checkAccess unnecessarily grabs the scheduler lock
> --------------------------------------------------------------------
>
> Key: YARN-3137
> URL: https://issues.apache.org/jira/browse/YARN-3137
> Project: Hadoop YARN
> Issue Type: Bug
> Affects Versions: 2.5.0
> Reporter: Jason Lowe
>
> The queues are stored in a ConcurrentHashMap and the code already checks for
> a null queue. At best we need to lock individual queues when processing the
> access check, but I don't see why we need to grab the highly-contested
> scheduler lock to lookup which queue to use for the hasAccess call.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
