Karthik Kambatla commented on YARN-2975:

bq. The removeApp from one operation is now 2 steps.
removeApp did not expose the two operations outside, but had them. 

IIUC, an app can only go from non-runnable to runnable, but not vice-versa. For 
instance, see the following snippet in FairScheduler#executeMove. So, don't 
think we need to worry about consistency. 
    if (wasRunnable && !nowRunnable) {
      throw new IllegalStateException("Should have already verified that app "
          + attempt.getApplicationId() + " would be runnable in new queue");

suggest resetPreemptedResources -> resetPreemptedResourcesRunnableApps
clearPreemptedResources -> clear PreemptedResourcesRunnableApps
I thought of this, but decided against it. The additional RunnableApps doesn't 
add anything but extra characters. 

> FSLeafQueue app lists are accessed without required locks
> ---------------------------------------------------------
>                 Key: YARN-2975
>                 URL: https://issues.apache.org/jira/browse/YARN-2975
>             Project: Hadoop YARN
>          Issue Type: Bug
>    Affects Versions: 2.6.0
>            Reporter: Karthik Kambatla
>            Assignee: Karthik Kambatla
>            Priority: Blocker
>         Attachments: yarn-2975-1.patch
> YARN-2910 adds explicit locked access to runnable and non-runnable apps in 
> FSLeafQueue. As FSLeafQueue has getters for these, they can be accessed 
> without locks in other places. 

This message was sent by Atlassian JIRA

Reply via email to