Return-Path: Delivered-To: apmail-hadoop-core-dev-archive@www.apache.org Received: (qmail 2104 invoked from network); 29 Apr 2008 04:43:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 29 Apr 2008 04:43:43 -0000 Received: (qmail 99119 invoked by uid 500); 29 Apr 2008 04:43:42 -0000 Delivered-To: apmail-hadoop-core-dev-archive@hadoop.apache.org Received: (qmail 99085 invoked by uid 500); 29 Apr 2008 04:43:42 -0000 Mailing-List: contact core-dev-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: core-dev@hadoop.apache.org Delivered-To: mailing list core-dev@hadoop.apache.org Received: (qmail 99074 invoked by uid 99); 29 Apr 2008 04:43:41 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 28 Apr 2008 21:43:41 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Apr 2008 04:42:54 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 7E11F234C107 for ; Mon, 28 Apr 2008 21:39:56 -0700 (PDT) Message-ID: <1533905403.1209443996515.JavaMail.jira@brutus> Date: Mon, 28 Apr 2008 21:39:56 -0700 (PDT) From: "Joydeep Sen Sarma (JIRA)" To: core-dev@hadoop.apache.org Subject: [jira] Commented: (HADOOP-153) skip records that throw exceptions MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/HADOOP-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12592950#action_12592950 ] Joydeep Sen Sarma commented on HADOOP-153: ------------------------------------------ > That is, even though recordreaders might not have the logic to determine whether a particular record is corrupt, the framework can do it with some help from the reader > If the record reader can identify bad records and skip them, then the framework need not get involved in the beginning of this jira - it was mentioned that problems from recordreader.next() were also covered in this jira. I take it from these comments - that this is not the case any more. it seems to me that if a recordreader can skip a record reliably (which is the support required from record readers from this jira) - then it will also be able to avoid throwing exceptions (since quite obviously, it can catch any exceptions and invoke the logic to skip to the next record within the next() body). just wanted to make sure since this jira was mentioned as something that might preempt 3144 (putting basic corruption detection code in the linerecordreader) - but that doesn't seem like the case .. > 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 > > 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.