Craig Welch commented on YARN-3251:

bq. 1) Since the target of your patch is to make a quick fix for old version, 
it's better to create a patch in branch-2.6
bq. And patch I'm working on now will remove the 
CSQueueUtils.computeMaxAvailResource, so it's no need to add a intermediate fix 
in branch-2.
I suppose that depends on whether anyone needs a trunk version of the patch 
before the other changes are landed - if someone asks for it I could quickly 
update the original patch to provide it
bq. 2) I think CSQueueUtils.getAbsoluteMaxAvailCapacity doesn't hold 
child/parent's lock together, maybe we don't need to change that, could you 
it doesn't, the change there was to insure consistency for multiple values used 
from the queue, as previously it was occurring inside a lock and that was 
guaranteed, now it isn't.  However, there's no need to lock on the parent, so I 
removed that 
bq. 3) Maybe we don't need getter/setter of absoluteMaxAvailCapacity in queue, 
a volatile float is enough?
Yes, that should be safe, done

> CapacityScheduler deadlock when computing absolute max avail capacity (short 
> term fix for 2.6.1)
> ------------------------------------------------------------------------------------------------
>                 Key: YARN-3251
>                 URL: https://issues.apache.org/jira/browse/YARN-3251
>             Project: Hadoop YARN
>          Issue Type: Bug
>    Affects Versions: 2.6.0
>            Reporter: Jason Lowe
>            Assignee: Craig Welch
>            Priority: Blocker
>         Attachments: YARN-3251.1.patch, YARN-3251.2-6-0.2.patch
> The ResourceManager can deadlock in the CapacityScheduler when computing the 
> absolute max available capacity for user limits and headroom.

This message was sent by Atlassian JIRA

Reply via email to