[
https://issues.apache.org/jira/browse/MAPREDUCE-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14511117#comment-14511117
]
Jason Lowe commented on MAPREDUCE-6324:
---------------------------------------
bq. One nit: testAllocResponseId is not really validating that responseIDs are
changing?
It does because it fails if LocalContainerAllocator doesn't have the patch.
The assert is in the MockScheduler class that increments the response ID with
each allocate call and sends it back in the response, just like the real
ApplicationMasterService. The MockScheduler asserts that the response ID of
allocate requests match the last response ID sent.
> Uber jobs fail to update AMRM token when it rolls over
> ------------------------------------------------------
>
> Key: MAPREDUCE-6324
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-6324
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: mr-am
> Affects Versions: 2.6.0
> Reporter: Jason Lowe
> Assignee: Jason Lowe
> Priority: Blocker
> Attachments: MAPREDUCE-6324.001.patch, MAPREDUCE-6324.002.patch
>
>
> When the RM rolls a new AMRM master key the AMs are supposed to receive a new
> AMRM token on subsequent heartbeats between the time when the new key is
> rolled and when it is activated. This is not occurring for uber jobs. If
> the connection to the RM needs to be re-established after the new key is
> activated (e.g.: RM restart or network hiccup) then the uber job AM will be
> unable to reconnect to the RM.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
