Return-Path: 
 <dev-return-236172-apmail-lucene-dev-archive=lucene.apache.org@lucene.apache.org>
X-Original-To: apmail-lucene-dev-archive@www.apache.org
Delivered-To: apmail-lucene-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id AC98D18D6F
	for <apmail-lucene-dev-archive@www.apache.org>;
 Fri, 19 Feb 2016 14:24:19 +0000 (UTC)
Received: (qmail 1007 invoked by uid 500); 19 Feb 2016 14:24:18 -0000
Delivered-To: apmail-lucene-dev-archive@lucene.apache.org
Received: (qmail 939 invoked by uid 500); 19 Feb 2016 14:24:18 -0000
Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@lucene.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@lucene.apache.org>
List-Post: <mailto:dev@lucene.apache.org>
List-Id: <dev.lucene.apache.org>
Reply-To: dev@lucene.apache.org
Delivered-To: mailing list dev@lucene.apache.org
Received: (qmail 915 invoked by uid 99); 19 Feb 2016 14:24:18 -0000
Received: from arcas.apache.org (HELO arcas) (140.211.11.28)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Feb 2016 14:24:18 +0000
Received: from arcas.apache.org (localhost [127.0.0.1])
	by arcas (Postfix) with ESMTP id 1E6712C14F4
	for <dev@lucene.apache.org>; Fri, 19 Feb 2016 14:24:18 +0000 (UTC)
Date: Fri, 19 Feb 2016 14:24:18 +0000 (UTC)
From: "Mark Miller (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <JIRA.12385211.1198694154000.93733.1455891858120@Atlassian.JIRA>
In-Reply-To: <JIRA.12385211.1198694154000@Atlassian.JIRA>
References: <JIRA.12385211.1198694154000@Atlassian.JIRA>
 <JIRA.12385211.1198694154621@arcas>
Subject: [jira] [Commented] (SOLR-445) Update Handlers abort with bad
 documents
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


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

Mark Miller commented on SOLR-445:
----------------------------------

{code}
      if ("LeaderChanged".equals(cause)) {
        // let's just fail this request and let the client retry? or just call processAdd again?
        log.error("On "+cloudDesc.getCoreNodeName()+", replica "+replicaUrl+
            " now thinks it is the leader! Failing the request to let the client retry! "+error.e);
        errorsForClient.add(error);
        break; // nocommit: why not continue?
      }
{code}

Been thinking about this a little. Perhaps the idea is, we know the error is not from a forward request, we skip those here. Which means they must all be leader to replica and if the leader changed, we can't put anyone in LIR anyway.
Anyhow, it does seems safer to me to not break and process all the errors.

> Update Handlers abort with bad documents
> ----------------------------------------
>
>                 Key: SOLR-445
>                 URL: https://issues.apache.org/jira/browse/SOLR-445
>             Project: Solr
>          Issue Type: Improvement
>          Components: update
>    Affects Versions: 1.3
>            Reporter: Will Johnson
>            Assignee: Hoss Man
>         Attachments: SOLR-445-3_x.patch, SOLR-445-alternative.patch, SOLR-445-alternative.patch, SOLR-445-alternative.patch, SOLR-445-alternative.patch, SOLR-445.patch, SOLR-445.patch, SOLR-445.patch, SOLR-445.patch, SOLR-445.patch, SOLR-445.patch, SOLR-445.patch, SOLR-445.patch, SOLR-445.patch, SOLR-445_3x.patch, solr-445.xml
>
>
> Has anyone run into the problem of handling bad documents / failures mid batch.  Ie:
> <add>
>   <doc>
>     <field name="id">1</field>
>   </doc>
>   <doc>
>     <field name="id">2</field>
>     <field name="myDateField">I_AM_A_BAD_DATE</field>
>   </doc>
>   <doc>
>     <field name="id">3</field>
>   </doc>
> </add>
> Right now solr adds the first doc and then aborts.  It would seem like it should either fail the entire batch or log a message/return a code and then continue on to add doc 3.  Option 1 would seem to be much harder to accomplish and possibly require more memory while Option 2 would require more information to come back from the API.  I'm about to dig into this but I thought I'd ask to see if anyone had any suggestions, thoughts or comments.    



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org