[
https://issues.apache.org/jira/browse/YARN-3137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14306130#comment-14306130
]
Jason Lowe commented on YARN-3137:
----------------------------------
bq. Queue hierarchy may change at any point of time due to refreshQueues.
True. I don't think we'd ever crash while walking the hierarchy as it changes,
but I think we could walk a path that never actually existed before or after
the refresh if queue parents were radically shifted. We can probably leverage
a read-write lock designed to control the queue hierarchy. The portion of node
updates and things like checkAccess would be readers when they need to walk the
hierarchy, and only the super-rare reinitialize would be a writer.
> CapacityScheduler.checkAccess unnecessarily grabs the scheduler lock
> --------------------------------------------------------------------
>
> Key: YARN-3137
> URL: https://issues.apache.org/jira/browse/YARN-3137
> Project: Hadoop YARN
> Issue Type: Sub-task
> Affects Versions: 2.5.0
> Reporter: Jason Lowe
> Assignee: Varun Saxena
>
> 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)
