Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: yarn-issues@hadoop.apache.org
Date: Wed, 5 Mar 2014 23:48:49 +0000 (UTC)
From: "Vinod Kumar Vavilapalli (JIRA)" <jira@apache.org>
To: yarn-issues@hadoop.apache.org
Message-ID: <JIRA.12679146.1384399614176.10104.1394063329224@arcas>
In-Reply-To: <JIRA.12679146.1384399614176@arcas>
References: <JIRA.12679146.1384399614176@arcas>
Subject: [jira] [Commented] (YARN-1410) Handle RM fails over after
 getApplicationID() and before submitApplication().
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/YARN-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13921649#comment-13921649 ] 

Vinod Kumar Vavilapalli commented on YARN-1410:
-----------------------------------------------

Tx for the clarification. 

bq.If we really think this check is un-necessary, we should at least document this in yarnClient#submitApplication()
Not only just documenting it, let's explicitly catch such apps and reject them.

bq. I do not think we need make any changes. DistributedShell and MapReduce has applicationId before submits the application.
Tx, I misinterpreted that we are changing the app-IDs.

Let's track the validation of AppIDs separately.

> 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.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)