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

Tomás Fernández Löbbe commented on SOLR-445:
--------------------------------------------

I uploaded a new patch with more javadocs and the test chains name changed. 
{quote}
even if "maxErrors" isn't reached, we should consider carefully whether or not 
it makes sense to be returning a "200" status code even if every update command 
that's executed for a request fails. (ie: if maxErrors defaults to 
Integer.MAX_VALUE, and i send 100 docs and all 100 fail, should i really get a 
200 status code back?)
{quote}
I think this would make it more confusing. Having this processor means that the 
client wants to manage failing docs on their side. If all the docs fail so be 
it, they’ll know how to manage it on their side, I don’t think that should be a 
special case. Plus, I think getting the 200 gives you more information, it 
tells you that Solr tried adding all the docs the client sent and it didn’t 
abort somewhere in the middle, like it would happen if you get a 4XX/5XX

I was also thinking that this processor won’t work together with 
DistributedUpdateProcessor, it has its own error processing, plus the 
distribution would create multiple internal requests (chains too) right? Also, 
the ConcurrentUpdateSolrServer used in SolrCmdDistributor would batch docs in a 
non-deterministic way, right? Would be impossible to count errors at this 
level. 


> 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
>             Fix For: 4.9, 5.0
>
>         Attachments: SOLR-445-3_x.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_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.2#6252)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to