hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xuan Gong (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-1410) Handle client failover during 2 step client API's like app submission
Date Sun, 29 Dec 2013 21:39:50 GMT

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

Xuan Gong commented on YARN-1410:
---------------------------------

bq.Should we leave adding all rpc annotations to the jira created for that purpose?

Sure. We will fix them on YARN-1521.

bq.Also, for the approach in this jira, the existing appId may have already been exposed to
the user. The user could have obtained the appId from the RM and set it on the AppSubmissionContext
and then submitted the app. So I dont think it would be right for us to replace that appId
with a new appId.

Yes, you are right. That is why I add comments on yarnClient#createApplication() and yarnClient#submitApplication()
to ask the clients that always use the applicationId returned by submitApplication() instead
of createApplication().

There is an another way to do it is that we can incorporate the createApplication() into submitApplication().
So, the users can directly use submitApplication(). But we have to change the yarnclient apis.

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

Mime
View raw message