[
https://issues.apache.org/jira/browse/YARN-540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13766032#comment-13766032
]
Jian He commented on YARN-540:
------------------------------
Thanks for the detailed comments, upload a new patch
bq. there is a member variable in AMRMClient that is used to get the ping
interval from config
Turns out we have one in AMRMClientAsync but not in AMRMClientImpl,
bq. Is delete not throwing an exception for non-existent location?
Delete throws exception in case of not-existing
bq. Can RMAppEventType.ATTEMPT_FAILED be received when in REMOVING state (and
also when in FINISHING state)?
Once we moved to REMOVING/FINISHING state, it indicates attempt goes to
FINISHING state, it should not be possible to generate
RMAppEventType.ATTEMPT_FAILED event at that state
bq. What is the YARNApplicationState enum corresponding to AppState.REMOVING?
In case of REMOVING, return YARNApplicationState as RUNNING, makes sense?
Addressed other comments also.
> Race condition causing RM to potentially relaunch already unregistered AMs on
> RM restart
> ----------------------------------------------------------------------------------------
>
> Key: YARN-540
> URL: https://issues.apache.org/jira/browse/YARN-540
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: resourcemanager
> Reporter: Jian He
> Assignee: Jian He
> Attachments: YARN-540.1.patch, YARN-540.2.patch, YARN-540.3.patch,
> YARN-540.4.patch, YARN-540.5.patch, YARN-540.6.patch, YARN-540.7.patch,
> YARN-540.patch, YARN-540.patch
>
>
> When job succeeds and successfully call finishApplicationMaster, RM shutdown
> and restart-dispatcher is stopped before it can process REMOVE_APP event. The
> next time RM comes back, it will reload the existing state files even though
> the job is succeeded
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
