Mailing-List: contact mapreduce-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mapreduce-issues@hadoop.apache.org
Date: Tue, 19 Mar 2013 17:39:15 +0000 (UTC)
From: "Bikas Saha (JIRA)" <jira@apache.org>
To: mapreduce-issues@hadoop.apache.org
Message-ID: <JIRA.12637619.1363636339290.12797.1363714755910@arcas>
In-Reply-To: <JIRA.12637619.1363636339290@arcas>
References: <JIRA.12637619.1363636339290@arcas>
Subject: [jira] [Commented] (MAPREDUCE-5079) Recovery should restore task
 state from job history info directly
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/MAPREDUCE-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13606567#comment-13606567 ] 

Bikas Saha commented on MAPREDUCE-5079:
---------------------------------------

+1 for the approach as the current one of full fidelity replay, while great when it works, is subject to being brittle. Similar approach is followed for restoring the RM state in which the AppManager, App and AppAttempt are handed their respective state payloads from which  they restore their respective states.
                
> 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
>         Attachments: 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