Return-Path: X-Original-To: apmail-hadoop-yarn-issues-archive@minotaur.apache.org Delivered-To: apmail-hadoop-yarn-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4E5AB10964 for ; Thu, 2 Jan 2014 22:43:52 +0000 (UTC) Received: (qmail 52162 invoked by uid 500); 2 Jan 2014 22:43:52 -0000 Delivered-To: apmail-hadoop-yarn-issues-archive@hadoop.apache.org Received: (qmail 52139 invoked by uid 500); 2 Jan 2014 22:43:52 -0000 Mailing-List: contact yarn-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: yarn-issues@hadoop.apache.org Delivered-To: mailing list yarn-issues@hadoop.apache.org Received: (qmail 52109 invoked by uid 99); 2 Jan 2014 22:43:52 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Jan 2014 22:43:52 +0000 Date: Thu, 2 Jan 2014 22:43:52 +0000 (UTC) From: "Xuan Gong (JIRA)" To: yarn-issues@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (YARN-1410) Handle client failover during 2 step client API's like app submission MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/YARN-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13860887#comment-13860887 ] Xuan Gong commented on YARN-1410: --------------------------------- Thanks for the comments. [~bikassaha], [~kkambatl] bq.But I think we have a separate createApplication() in order to get an appId for which to request RM tokens so that those tokens can be inserted in the AppSubmitContext before app submission Looks like that requesting RM tokens request does not need appId. But I agree that we still need createApplication(). By using this function, it can give us a global unique Id, we can use this Id to do several things, such as create JobId for mapreduce job, use it as part of Path to set up the local resource. For the solution of this ticket, I think the better way is to ask client to alway use the submitApplication() (adding comments on yarnClient api). In submitApplication(), we can check whether the appid is provided from ASC or not, if it does, we can use this appid (of course, need to check whether this appid is provided by current active rm or not) to submit the application. If not, we can ask one, then do the submission. > Handle client failover during 2 step client API's like app submission > --------------------------------------------------------------------- > > 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.1.patch > > > 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.1.5#6160)