[
https://issues.apache.org/jira/browse/YARN-7630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16291715#comment-16291715
]
Hudson commented on YARN-7630:
------------------------------
SUCCESS: Integrated in Jenkins build Hadoop-trunk-Commit #13379 (See
[https://builds.apache.org/job/Hadoop-trunk-Commit/13379/])
YARN-7630. Fix AMRMToken rollover handling in AMRMProxy. Contributed by (subru:
rev 17ba74be29193ac15474f73baaaf4e647a95078b)
* (edit)
hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-common/src/main/java/org/apache/hadoop/yarn/server/utils/AMRMClientUtils.java
> Fix AMRMToken rollover handling in AMRMProxy
> --------------------------------------------
>
> Key: YARN-7630
> URL: https://issues.apache.org/jira/browse/YARN-7630
> Project: Hadoop YARN
> Issue Type: Sub-task
> Reporter: Botong Huang
> Assignee: Botong Huang
> Priority: Minor
> Fix For: 3.1.0, 2.10.0, 2.9.1
>
> Attachments: YARN-7630.v1.patch, YARN-7630.v1.patch
>
>
> Symptom: after RM rolls over the master key for AMRMToken, whenever the RPC
> connection from FederationInterceptor to RM breaks due to transient network
> issue and reconnects, heartbeat to RM starts failing because of the “Invalid
> AMRMToken” exception. Whenever it hits, it happens for both home RM and
> secondary RMs.
> Related facts:
> 1. When RM issues a new AMRMToken, it always send with service name field as
> empty string. RPC layer in AM side will set it properly before start using
> it.
> 2. UGI keeps all tokens using a map from serviceName->Token. Initially
> AMRMClientUtils.createRMProxy() is used to load the first token and start the
> RM connection.
> 3. When RM renew the token, YarnServerSecurityUtils.updateAMRMToken() is used
> to load it into UGI and replace the existing token (with the same serviceName
> key).
> Bug:
> The bug is that 2-AMRMClientUtils.createRMProxy() and
> 3-YarnServerSecurityUtils.updateAMRMToken() is not handling the sequence
> consistently. We always need to load the token (with empty service name) into
> UGI first before we set the serviceName, so that the previous AMRMToken will
> be overridden. But 2 is doing it reversely. That’s why after RM rolls the
> amrmToken, the UGI end up with two tokens. Whenever the RPC connection break
> and reconnect, the wrong token could be picked and thus trigger the
> exception.
> Fix:
> Should load the AMRMToken into UGI first and then update the service name
> field for RPC
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
