MENG DING commented on YARN-4519:

This approach would be simpler, at the expense of acquiring a CS lock in the 
allocate call (though no worse than existing logic). 

I also think that it is necessary to move the logic of creating 
normalizedDecreaseRequests (i.e. SchedContainerChangeRequest) into the 
decreaseContainer() call (under the scope of CS lock), otherwise there would be 
race condition when creating the delta resources. What do you think?

> potential deadlock of CapacityScheduler between decrease container and assign 
> containers
> ----------------------------------------------------------------------------------------
>                 Key: YARN-4519
>                 URL: https://issues.apache.org/jira/browse/YARN-4519
>             Project: Hadoop YARN
>          Issue Type: Bug
>          Components: capacityscheduler
>            Reporter: sandflee
> In CapacityScheduler.allocate() , first get FiCaSchedulerApp sync lock, and 
> may be get CapacityScheduler's sync lock in decreaseContainer()
> In scheduler thread,  first get CapacityScheduler's sync lock in 
> allocateContainersToNode(), and may get FiCaSchedulerApp sync lock in 
> FicaSchedulerApp.assignContainers(). 

This message was sent by Atlassian JIRA

Reply via email to