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 80A1810348 for ; Wed, 26 Mar 2014 17:33:23 +0000 (UTC) Received: (qmail 92699 invoked by uid 500); 26 Mar 2014 17:33:21 -0000 Delivered-To: apmail-hadoop-yarn-issues-archive@hadoop.apache.org Received: (qmail 92513 invoked by uid 500); 26 Mar 2014 17:33:19 -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 92454 invoked by uid 99); 26 Mar 2014 17:33:17 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Mar 2014 17:33:17 +0000 Date: Wed, 26 Mar 2014 17:33:17 +0000 (UTC) From: "Bikas Saha (JIRA)" To: yarn-issues@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (YARN-1521) Mark appropriate protocol methods with the idempotent annotation or AtMostOnce annotation 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-1521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13948184#comment-13948184 ] Bikas Saha commented on YARN-1521: ---------------------------------- How are the following idempotent? Looks like submitApplication was made idempotent in this patch itself? What about moveApplication? If the app has been moved from A->B then asking another move from A would be an error. So a retry after the operation should also return an error unless there is specific handling for the retry. {code} + @Idempotent public SubmitApplicationResponse submitApplication( SubmitApplicationRequest request) + @Idempotent public MoveApplicationAcrossQueuesResponse moveApplicationAcrossQueues( {code} IMO, how can we simply create an empty response and return it? Currently this is safe because that response object has no fields. But if a field is added tomorrow then this code would be wrong since users would get a response object from which they cannot get response information. We should be using RetryCache to populate the response from the actual response that was returned for the original request that got retried. {code}- throw RPCUtil.getRemoteException(message); + LOG.info("This is an earlier submitted application: " + applicationId); + return SubmitApplicationResponse.newInstance();{code} > Mark appropriate protocol methods with the idempotent annotation or AtMostOnce annotation > ----------------------------------------------------------------------------------------- > > Key: YARN-1521 > URL: https://issues.apache.org/jira/browse/YARN-1521 > Project: Hadoop YARN > Issue Type: Sub-task > Reporter: Xuan Gong > Assignee: Xuan Gong > Priority: Blocker > Fix For: 2.4.0 > > Attachments: YARN-1521.0.patch, YARN-1521.1.patch, YARN-1521.2.patch, YARN-1521.3.patch > > > After YARN-1028, we add the automatically failover into RMProxy. This JIRA is to identify whether we need to add idempotent annotation and which methods can be marked as idempotent. -- This message was sent by Atlassian JIRA (v6.2#6252)