[
https://issues.apache.org/jira/browse/YARN-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13645288#comment-13645288
]
Vinod Kumar Vavilapalli commented on YARN-599:
----------------------------------------------
Hm, it isn't straight-forward to figure that failures during
RMAppManager.submitApplication() are properly put in Audit logs. But they are,
I just verified.
The latest patch looks good to me. +1, checking it in..
> Refactoring submitApplication in ClientRMService and RMAppManager
> -----------------------------------------------------------------
>
> Key: YARN-599
> URL: https://issues.apache.org/jira/browse/YARN-599
> Project: Hadoop YARN
> Issue Type: Bug
> Reporter: Zhijie Shen
> Assignee: Zhijie Shen
> Attachments: YARN-599.1.patch, YARN-599.2.patch
>
>
> Currently, ClientRMService#submitApplication call RMAppManager#handle, and
> consequently call RMAppMangager#submitApplication directly, though the code
> looks like scheduling an APP_SUBMIT event.
> In addition, the validation code before creating an RMApp instance is not
> well organized. Ideally, the dynamic validation, which depends on the RM's
> configuration, should be put in RMAppMangager#submitApplication.
> RMAppMangager#submitApplication is called by
> ClientRMService#submitApplication and RMAppMangager#recover. Since the
> configuration may be changed after RM restarts, the validation needs to be
> done again even in recovery mode. Therefore, resource request validation,
> which based on min/max resource limits, should be moved from
> ClientRMService#submitApplication to RMAppMangager#submitApplication. On the
> other hand, the static validation, which is independent of the RM's
> configuration should be put in ClientRMService#submitApplication, because it
> is only need to be done once during the first submission.
> Furthermore, try-catch flow in RMAppMangager#submitApplication has a flaw.
> RMAppMangager#submitApplication has a flaw is not synchronized. If two
> application submissions with the same application ID enter the function, and
> one progresses to the completion of RMApp instantiation, and the other
> progresses the completion of putting the RMApp instance into rmContext, the
> slower submission will cause an exception due to the duplicate application
> ID. However, the exception will cause the RMApp instance already in rmContext
> (belongs to the faster submission) being rejected with the current code flow.
--
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
