[ 
https://issues.apache.org/jira/browse/HADOOP-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12577231#action_12577231
 ] 

Doug Cutting commented on HADOOP-153:
-------------------------------------

The tricky bit will be identifying the failed record number, no?  The naive 
approach would be to have the child report after each record has been 
processed, so that the parent can then know, when it crashes, which record it 
was on.  But that would probably be too expensive.

So rather we might have the child report in its TaskStatus the range of record 
numbers it intends to process before it next reports.  Then, on failure, the 
parent knows that skipping that range will skip the offending record.  The 
child can adaptively choose a range that keeps the status update time within 
reason.  It would start by reporting range 0-1, then use the time required to 
process that entry to determine how big of a range to send the next time and 
still provide timely updates.  If a particular record takes a long time, then 
it can update status before the range is exhausted, providing a new range.

Would this be acceptable, to skip a few more than just the offending record?


> skip records that throw exceptions
> ----------------------------------
>
>                 Key: HADOOP-153
>                 URL: https://issues.apache.org/jira/browse/HADOOP-153
>             Project: Hadoop Core
>          Issue Type: New Feature
>          Components: mapred
>    Affects Versions: 0.2.0
>            Reporter: Doug Cutting
>            Assignee: Devaraj Das
>             Fix For: 0.17.0
>
>
> MapReduce should skip records that throw exceptions.
> If the exception is thrown under RecordReader.next() then RecordReader 
> implementations should automatically skip to the start of a subsequent record.
> Exceptions in map and reduce implementations can simply be logged, unless 
> they happen under RecordWriter.write().  Cancelling partial output could be 
> hard.  So such output errors will still result in task failure.
> This behaviour should be optional, but enabled by default.  A count of errors 
> per task and job should be maintained and displayed in the web ui.  Perhaps 
> if some percentage of records (>50%?) result in exceptions then the task 
> should fail.  This would stop jobs early that are misconfigured or have buggy 
> code.
> Thoughts?

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

Reply via email to