Rohith commented on YARN-2865:

bq. why does the rmContext still contain the application?If the RM were at 
standby mode, the transitionToStandby should have cleaned the rmContext up ?
I agree in positive flow. What if trainsitionToActive throw exception after 
recovery is succeeded?? Recovery process adds back applications to RMContext in 
RMAppManager. Any service start failures occur after recovery is completed then 
RMContext remain with stale applications.
Consider the below scenario execution
# RM is in StandBy state. Initial state is STANDBY
## Recovery : All application recovery is success. RMContext has recovered 
applications in it.
## Any active service start failed which throw exception back.
   RM state remain STANDBY. But here, exception handling is done i.e. only 
dispatcher has been reset, but not rmcontext/metrics system. Currently, it is 
done at  {{stopActiveService ()}}
# STANDBY to ACTIVE : recovery fails with above exception. And it never move to 
ACTIVE in further transtitionToActive command from elector unless RM gets 
command to STANDBY to STANDBY and next  STANDBY to ACTIVE.


> Application recovery continuously fails with "Application with id already 
> present. Cannot duplicate"
> ----------------------------------------------------------------------------------------------------
>                 Key: YARN-2865
>                 URL: https://issues.apache.org/jira/browse/YARN-2865
>             Project: Hadoop YARN
>          Issue Type: Bug
>          Components: resourcemanager
>            Reporter: Rohith
>            Assignee: Rohith
>            Priority: Critical
>         Attachments: YARN-2865.patch
> YARN-2588 handles exception thrown while transitioningToActive and reset 
> activeServices. But it misses out clearing RMcontext apps/nodes details and 
> ClusterMetrics and QueueMetrics. This causes application recovery to fail.  

This message was sent by Atlassian JIRA

Reply via email to