[
https://issues.apache.org/jira/browse/YARN-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14161499#comment-14161499
]
Tsuyoshi OZAWA commented on YARN-1879:
--------------------------------------
Thanks for your comments, Jian and Karthik.
{quote}
from RM’s perspective, these are just new requests, as the new RM doesn’t have
any cache for previous requests from client.
{quote}
I confirmed that it's true. Not only {{finishApplicationMaster}} but also
{{registerApplicationMaster}} don't touch the data in ZK directly, so RM can
handle retried requests transparently following cases:
1. When EmbeddedElector choose different RM as a leader before and after the
failover, ZK doesn't have the data of RMAttempt/RMApp. Then, RM recognizes a
retried-request as a new request. e.g. there is active-RM(RM1) and
standby-RM(RM2) and RM's leader failovers from RM1 to RM2.
2. Still when EmbeddedElector choose same RM as a leader before and after the
failover, RM goes into standby state and RM stop all services before failover
and it reload the data of RMAppAttempt/RMApp. In this case, RM recognizes a
retried-request as a new request. e.g. there is active-RM(RM1) and
standby-RM(RM2) and RM's leader failovers from RM1 to RM1.
I think it has no problem to mark these methods as Idempotent.
> Mark Idempotent/AtMostOnce annotations to ApplicationMasterProtocol for RM
> fail over
> ------------------------------------------------------------------------------------
>
> Key: YARN-1879
> URL: https://issues.apache.org/jira/browse/YARN-1879
> Project: Hadoop YARN
> Issue Type: Sub-task
> Components: resourcemanager
> Reporter: Jian He
> Assignee: Tsuyoshi OZAWA
> Priority: Critical
> Attachments: YARN-1879.1.patch, YARN-1879.1.patch,
> YARN-1879.11.patch, YARN-1879.12.patch, YARN-1879.13.patch,
> YARN-1879.14.patch, YARN-1879.15.patch, YARN-1879.16.patch,
> YARN-1879.17.patch, YARN-1879.18.patch, YARN-1879.19.patch,
> YARN-1879.2-wip.patch, YARN-1879.2.patch, YARN-1879.20.patch,
> YARN-1879.21.patch, YARN-1879.22.patch, YARN-1879.3.patch, YARN-1879.4.patch,
> YARN-1879.5.patch, YARN-1879.6.patch, YARN-1879.7.patch, YARN-1879.8.patch,
> YARN-1879.9.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
