This has been hanging around for a long time. I did some preliminary work
here: https://issues.apache.org/jira/browse/SOLR-445 but moved on to other
things before committing it. The discussion there might be useful.
FWIW,
Erick
On Wed, Feb 27, 2013 at 5:32 AM, Mikhail Khludnev <
mkhlud...@griddy
Colleagues,
Here are my considerations
If the exception is occurs somewhere in updateprocessor we can add a
special update processor on top of the head of update processor chain,
which will catch exception from delegated processAdd call, log and/or
swallow it.
If it fits for the purpose we can tr
Ideally you would want to use SOLRJ or other interface which can catch
exceptions/error and re-try them.
On Tue, Feb 26, 2013 at 3:45 PM, Walter Underwood wrote:
> I've done exactly the same thing. On error, set the batch size to one and
> try again.
>
> wunder
>
> On Feb 26, 2013, at 12:27 PM,
I've done exactly the same thing. On error, set the batch size to one and try
again.
wunder
On Feb 26, 2013, at 12:27 PM, Timothy Potter wrote:
> Here's what I do to work-around failures when processing batches of updates:
>
> On client side, catch the exception that the batch failed. In the
>
Here's what I do to work-around failures when processing batches of updates:
On client side, catch the exception that the batch failed. In the
exception handler, switch to one-by-one mode for the failed batch
only.
This allows you to isolate the *bad* documents as well as getting the
*good* docum
Hi.
I add documents to Solr by POSTing them to UpdateHandler, as bulks of
commands (DIH is not used).
If one document contains any invalid data (e.g. string data into numeric
field), Solr returns HTTP 400 Bad Request, and the whole bulk is failed.
I'm searching for a way to tell Solr to accept
