[
https://issues.apache.org/jira/browse/YARN-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14238155#comment-14238155
]
Craig Welch commented on YARN-2925:
-----------------------------------
Hmm, there might be an even simpler approach - if we placed lock(s) (just a
single lock, or potentially read/write) in the LeafQueue and then just held
them around the final headroom calculation and the two locations where other
changes occur (user comsumed +- and queue usedResources +-), all of which I
believe occur in leaf queue, and then setup the lastClusterResource to be
copied (inside the (write)lock), I think this would be resolved, and it would
not be much of a change / much code. In fact, we would not need the
queueresourceinfo at all, and could potentially drop the headroominfo as well.
[~leftnoteasy] I think this might actually bethe simplest approach, Thoughts?
> Internal fields in LeafQueue access should be protected when accessed from
> FiCaSchedulerApp to calculate Headroom
> -----------------------------------------------------------------------------------------------------------------
>
> Key: YARN-2925
> URL: https://issues.apache.org/jira/browse/YARN-2925
> Project: Hadoop YARN
> Issue Type: Bug
> Components: capacityscheduler
> Reporter: Wangda Tan
> Assignee: Wangda Tan
> Priority: Critical
> Attachments: YARN-2925.1.patch
>
>
> Upon YARN-2644, FiCaScheduler will calculation up-to-date headroom before
> sending back Allocation response to AM.
> Headroom calculation is happened in LeafQueue side, uses fields like used
> resource, etc. But it is not protected by any lock of LeafQueue, so it might
> be corrupted is someone else is editing it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
