[
https://issues.apache.org/jira/browse/MAPREDUCE-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13150603#comment-13150603
]
Robert Joseph Evans commented on MAPREDUCE-3312:
------------------------------------------------
This is not a critical fix (it is major :)). This is just a follow up to
MAPREDUCE-3274 which fixed the deadlock problem, but did not fix all of the
underlying causes of the issue. We can hold off on it until MAPREDUCE-3355 and
MAPREDUCE-3402 are finished.
As a side note, the reason why I put the change into TaskAttemptImpl, is
because the only way to ensure that a container is launched/killed in the
proper order is to maintain some state for all containers. I was not sure if
The container Launcher should then be modified so that it was more like
TaskAttemptImpl, where it used the state machine library, or if just keeping
the state in a concurrent hash map.
> Make MR AM not send a stopContainer w/o corresponding start container
> ---------------------------------------------------------------------
>
> Key: MAPREDUCE-3312
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-3312
> Project: Hadoop Map/Reduce
> Issue Type: Bug
> Components: mrv2
> Affects Versions: 0.23.0, 0.24.0
> Reporter: Robert Joseph Evans
> Assignee: Robert Joseph Evans
> Fix For: 0.23.1
>
> Attachments: MR-3312.txt
>
>
> This is a follow on to MAPREDUCE-3274. It is possible, although rare, for
> the MR AM to send a stop container before it sends a start container. This
> needs to stop that from happening. If a stop is found first it should
> prevent the start from being sent. It tries to do this, but only if the stop
> is currently pending.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
