[
https://issues.apache.org/jira/browse/MAPREDUCE-6230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Lowe updated MAPREDUCE-6230:
----------------------------------
Attachment: MAPREDUCE-6230.001.patch
Based on [my comment from
YARN-3103|https://issues.apache.org/jira/browse/YARN-3103?focusedCommentId=14295216&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14295216]
here's a patch to store the token into the *current* UGI using whatever
service name the RM set as the key/alias to clobber the existing token and then
updates the service name *after* the token has been stored in the credentials.
Added a unit test and also manually tested the patch on a secure cluster where
the RM rolled the AMRM token master key and then restarted the RM after it
activated while the app was still running. Verified that before this fix the
AM failed to connect to the RM in that scenario but was able to succeed with
this patch.
> MR AM does not survive RM restart if RM activated a new AMRM secret key
> -----------------------------------------------------------------------
>
> Key: MAPREDUCE-6230
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6230
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: mr-am
> Reporter: Jason Lowe
> Assignee: Jason Lowe
> Priority: Blocker
> Attachments: MAPREDUCE-6230.001.patch
>
>
> A MapReduce AM will fail to reconnect to an RM that performed restart in the
> following scenario:
> # MapReduce job launched with AMRM token generated from AMRM secret X
> # RM rolls new AMRM secret Y and activates the new key
> # RM performs a work-preserving restart
> # MapReduce job AM now unable to connect to RM with "Invalid AMRMToken"
> exception
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
