Jian He commented on YARN-3103:

bq.  Not sure ClientRMProxy can even update the key/alias associated with the 
token in the Credentials
I see. looks like Credentials doesn't have a removeToken method. If so, we may 
remove the old token with the empty service name. And insert the new token with 
the correct service name as the key.

bq. if the RM knew, at the time of the AM launch context creation, what service 
name the AM would use to locate the RM.
Maybe use the cluster ID as the key ? active and standby RMs will share the 
same cluster ID. RMs from different cluster use different cluster IDs. 

> AMRMClientImpl does not update AMRM token properly
> --------------------------------------------------
>                 Key: YARN-3103
>                 URL: https://issues.apache.org/jira/browse/YARN-3103
>             Project: Hadoop YARN
>          Issue Type: Bug
>          Components: client
>    Affects Versions: 2.6.0
>            Reporter: Jason Lowe
>            Assignee: Jason Lowe
>            Priority: Blocker
> AMRMClientImpl.updateAMRMToken updates the token service _before_ storing it 
> to the credentials, so the token is mapped using the newly updated service 
> rather than the empty service that was used when the RM created the original 
> AMRM token.  This leads to two AMRM tokens in the credentials and can still 
> fail if the AMRMTokenSelector picks the wrong one.
> In addition the AMRMClientImpl grabs the login user rather than the current 
> user when security is enabled, so it's likely the UGI being updated is not 
> the UGI that will be used when reconnecting to the RM.
> The end result is that AMs can fail with invalid token errors when trying to 
> reconnect to an RM after a new AMRM secret has been activated.

This message was sent by Atlassian JIRA

Reply via email to