[
https://issues.apache.org/jira/browse/MAPREDUCE-5002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14735595#comment-14735595
]
Jason Lowe commented on MAPREDUCE-5002:
---------------------------------------
Thanks for the patch, Chang!
Main change of the patch looks good, just some issues with the test. I'm not a
fan of having the test reach into the bowels of a private variable in the class
and modify it directly. To me that's sort of an invalid setup. Instead the
test should be able to accomplish the task via normal interfaces, otherwise the
reported bug doesn't exist. In this case we should be able to send appropriate
allocate responses to convince the original code to accidentally grant a reduce
container to a map and see that the new code does not do this. It may be
simpler to mock up the AM protocol directly rather than using a MockRM to get
it to grant the excess containers required.
> AM could potentially allocate a reduce container to a map attempt
> -----------------------------------------------------------------
>
> Key: MAPREDUCE-5002
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-5002
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: mr-am
> Affects Versions: 2.0.3-alpha, 0.23.7, 2.7.0
> Reporter: Jason Lowe
> Assignee: Chang Li
> Attachments: MAPREDUCE-5002.1.patch, MAPREDUCE-5002.2.patch,
> MAPREDUCE-5002.2.patch
>
>
> As discussed in MAPREDUCE-4982, after MAPREDUCE-4893 it is theoretically
> possible for the AM to accidentally assign a reducer container to a map
> attempt if the AM doesn't find a reduce attempt actively looking for the
> container (e.g.: the RM accidentally allocated too many reducer containers).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
