[jira] Updated: (HADOOP-3245) Provide ability to persist running jobs (extend HADOOP-1876)

["Amar Kamat (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HADOOP-3245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Amar Kamat updated HADOOP-3245:
-------------------------------

    Attachment: HADOOP-3245-v5.33.1.patch

Attaching a new patch.
_Additions_ :
1) adds the switch (mapred.jobtracker.restart.recover) in {{hadoop-default.xml}} to turn on/off the recovery upon restart. By default the switch is switched *off*
2) some bug fixes
3) the test case now is improved to include
   - recovery switch test
   - matching the task completion events with the jobtracker and the task tracker upon restart

4) This patch now assumes HADOOP-3970 and hence will break if its missing.

_Test_ :
- Ran sort benchmark on 500 nodes with frequent restarts. Jobs resumes smoothly. 
- Killed a task-tracker while the jobtracker was down. The tracker was declared _lost_  and all the tasks that ran on the tracker got re-executed.

_Known issues_ :
1) {{jobhistory.jsp}} uses the history filename to infer the job's name. Upon restart, the history filename is added a _'.recover'_ extension. Hence running jobs on the history  page will show a _'.recover'_ along with the actual jobname. Note that the history filename is renamed upon completion and hence completed jobs will display the jobname correctly.
2) Every restart will create a *new* conf file in the history folder
3) Some reduce tasks show progress more than 100%. Looks like the reduce phase shows the progress more than expected. Since this patch doesnt touch the {{REDUCE}} phase I suspect that the {{Reduce}} phase progress-reporting code is buggy.
4) This patch still implements the greedy reconnect and hence few tasks gets scheduled unnecessarily. For now I dont think this is a concern. Something like a _safe-mode_ seems to be a solution but needs some more thought.
5) Devaraj's comment #9 [here|https://issues.apache.org/jira/browse/HADOOP-3245?focusedCommentId=12611539#action_12611539] about reducer's committing suicide is still not addressed.
6) In case where a map attempt is killed (externally/lost-tracker) and is not logged to history, it will take some time for the jobtracker to detect that the map is missing. Probably asking the task-trackers about what maps are currenly hosted seems to be a solution, this issue needs some more thought.

_Todo_ :
1) There are some extra logs for debugging. Remove that and add appropriate debug logs.

> Provide ability to persist running jobs (extend HADOOP-1876)
> ------------------------------------------------------------
>
>                 Key: HADOOP-3245
>                 URL: https://issues.apache.org/jira/browse/HADOOP-3245
>             Project: Hadoop Core
>          Issue Type: New Feature
>          Components: mapred
>            Reporter: Devaraj Das
>            Assignee: Amar Kamat
>         Attachments: HADOOP-3245-v2.5.patch, HADOOP-3245-v2.6.5.patch, HADOOP-3245-v2.6.9.patch, HADOOP-3245-v4.1.patch, HADOOP-3245-v5.13.patch, HADOOP-3245-v5.14.patch, HADOOP-3245-v5.26.patch, HADOOP-3245-v5.30-nolog.patch, HADOOP-3245-v5.31.3-nolog.patch, HADOOP-3245-v5.33.1.patch
>
>
> This could probably extend the work done in HADOOP-1876. This feature can be applied for things like jobs being able to survive jobtracker restarts.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.