[
https://issues.apache.org/jira/browse/MAPREDUCE-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Lowe updated MAPREDUCE-5079:
----------------------------------
Attachment: MAPREDUCE-5079.patch
Thanks for the in-depth review, Sidd! I addressed most of the review comments,
with a couple of exceptions:
* getPreviousJobHistoryFileStream had a useful log message in it, and since
JobHistoryUtils doesn't have a logger I refactored it into two parts:
JobHistoryUtils.getPreviousJobHistoryPath which gets the path and MRAppMaster
logs the result and opens it to get the stream.
* testRecoveryTaskSuccessAllAttemptsFail already was checking for a new attempt
being created by checking for an extra, third attempt in the NEW state. I
added a comment to the test to call that out.
* testRecoveryTaskSuccessAllAttemptsSucceed already is checking that the
JobEventType is returning a SUCCEEDED state in the checkRecovery method.
> Recovery should restore task state from job history info directly
> -----------------------------------------------------------------
>
> Key: MAPREDUCE-5079
> URL: https://issues.apache.org/jira/browse/MAPREDUCE-5079
> Project: Hadoop Map/Reduce
> Issue Type: Improvement
> Components: mr-am
> Affects Versions: 0.23.7
> Reporter: Jason Lowe
> Assignee: Jason Lowe
> Priority: Critical
> Attachments: MAPREDUCE-5079-branch-0.23.patch, MAPREDUCE-5079.patch,
> MAPREDUCE-5079.patch, MAPREDUCE-5079.patch, MAPREDUCE-5079.patch
>
>
> We've encountered a lot of hanging issues during MR-AM recovery because the
> state machines don't always end up in the same states after recovery. This
> is especially true when speculative execution is enabled. It should be
> straightforward to restore task and task attempt states directly from the
> TaskInfo and TaskAttemptInfo records in the job history file to avoid relying
> on the task state machines ending up in the proper states with the proper
> number of attempts.
> This should be a more robust solution that would also give us the option of
> recovering start time and log locations for tasks that were in-progress when
> the AM crashed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
