[
https://issues.apache.org/jira/browse/YARN-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13924265#comment-13924265
]
Xuan Gong commented on YARN-1410:
---------------------------------
For our current applications, distributedShell, mapreduce, etc, we use
applicationId as a global unique id, and we need this id to save the required
files, such as shell scripts, to generate job id for mapreduce jobs, etc. And
that is why we will get the applicationId before we submit this application.
For the compatibility, this applicationId should not be changed during the
submission process no matter the failover happens or not. So, we require the
user to provide the applicationId before they submit an application.
> Handle RM fails over after getApplicationID() and before submitApplication().
> -----------------------------------------------------------------------------
>
> Key: YARN-1410
> URL: https://issues.apache.org/jira/browse/YARN-1410
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Bikas Saha
> Assignee: Xuan Gong
> Attachments: YARN-1410-outline.patch, YARN-1410.1.patch,
> YARN-1410.10.patch, YARN-1410.10.patch, YARN-1410.2.patch, YARN-1410.2.patch,
> YARN-1410.3.patch, YARN-1410.4.patch, YARN-1410.5.patch, YARN-1410.6.patch,
> YARN-1410.7.patch, YARN-1410.8.patch, YARN-1410.9.patch
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> App submission involves
> 1) creating appId
> 2) using that appId to submit an ApplicationSubmissionContext to the user.
> The client may have obtained an appId from an RM, the RM may have failed
> over, and the client may submit the app to the new RM.
> Since the new RM has a different notion of cluster timestamp (used to create
> app id) the new RM may reject the app submission resulting in unexpected
> failure on the client side.
> The same may happen for other 2 step client API operations.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
