Jian He commented on YARN-3103:

thanks for reporting this issue, Jason !
IIUC, the root cause is that {{ClientRMProxy#setAMRMTokenService}} updates the 
service name of the token, but doesn't update the service key which is empty.  
(quick fix might be to fix this first.)
bq. RM should add the AMRM token to the credentials using a well-known 
identifier that the client can also use when updating it. 
Is it a valid future use-case that one AM talking with two RMs from separate 
clusters? If so, one AM may need to hold two AMRM tokens.

> 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