[
https://issues.apache.org/jira/browse/YARN-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13639848#comment-13639848
]
Zhijie Shen commented on YARN-599:
----------------------------------
In YARN-599.1.patch, there're the following changes:
1. ClientRMService#submitApplication calls RMAppManager#submitApplication
directly. APP_SUBMIT event is removed at all. RMAppManager#submitApplication
throws YarnRemoteException.
2. Move getCurrentUser and validateResourceRequest from
ClientRMService#submitApplication to RMAppManager#submitApplication. Move
getQueue and getApplicationName from RMAppManager#submitApplication to
ClientRMService#submitApplication. Adjust the test cases in TestClientRMService
and TestAppManger accordingly.
3. Refactor try-catch block in RMAppManager#submitApplication to avoid sending
APP_REJECTED event to existing app in rmContext given duplicate applicateId.
4. Refactor TestAppManger to extract common part of the tests and push them to
setup().
> 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
>
>
> 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
