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

Enis Soztutar commented on HADOOP-153:
--------------------------------------

bq. Instead of keeping bad records ids in JobTracker's TIP object, I would 
prefer keeping it in FileSystem along with other job files. This would allows 
us to be more scalable as no of bad records could potentially be high.
I think the number of bad records *supposed to be* low. If the job fails in 
lots of records, then there should be some problem with the implementation 
itself. 
I guess the number of bad records per job should be on the order of hundreds 
max. While working with nutch, there were just several records which caused 
StackOverflow by the third-party html parsers ,out of millions of urls.  
Can you give us an example percentage of bad records that you see in the jobs 
at Y!  

> 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: Sharad Agarwal
>         Attachments: skipRecords_wip1.patch
>
>
> 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