[
https://issues.apache.org/jira/browse/SOLR-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15154493#comment-15154493
]
Hoss Man commented on SOLR-445:
-------------------------------
bq. Can we document that on the setException method?
I'm not sure what exactly it should say, but that seems orthogonal to the
current issue -- feel free to add whatever you think makes sense as a distinct
git commit, my point was just that the current behavior is very inconsistent
with the way exceptions are normally processed in solr, and doesn't give "up
stream" callers the chance to catch/handle the exception.
bq. If we could get this out in a major version, I'd also love to make this
standard behavior and not some optional update processor.
Agreed - but for now, to minimize the invasiveness, I'd prefer to continue on
the path of using a custom update processor & then later we can assess
refactoring the code to make this a more integrated feature and change that
update processor to a No-Op.
(particularly since there is going to be some overhead in counting/tracking the
errors)
bq. Oh wait a minute, are you only doing that when maxErrors is exceeded? In
that case failing the request makes sense to me I guess.
yeah, that's the context of the question ... i'm leaning towards agreeing with
you, particularly since (as things stand now) the caller can access the SolrJ
exception metadata to see exactly what failed (but i really wish there was an
easier way to access the _full_ response body in those cases)
bq. Anyhow, it does seems safer to me to not break and process all the errors.
Yeah, that was my thinking.
> 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: [email protected]
For additional commands, e-mail: [email protected]
