[
https://issues.apache.org/jira/browse/SOLR-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18096177#comment-18096177
]
ASF subversion and git services commented on SOLR-3284:
-------------------------------------------------------
Commit 14e850357171b1fbf251ba3eb14e2f7628860aa1 in solr's branch
refs/heads/main from Serhiy Bzhezytskyy
[ https://gitbox.apache.org/repos/asf?p=solr.git;h=14e85035717 ]
SOLR-3284: let ConcurrentUpdateSolrClient report which docs failed to send
(#4632)
ConcurrentUpdateSolrClient can now report which documents failed to reach the
server.
Register a handler via the Builder's withErrorHandler(...) to recover the
documents of a failed batch, for example to route them to a retry queue or
dead-letter topic.
Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>
> ConcurrentUpdateSolrClient swallows exceptions
> ----------------------------------------------
>
> Key: SOLR-3284
> URL: https://issues.apache.org/jira/browse/SOLR-3284
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
> Affects Versions: 3.5, 4.0-ALPHA
> Reporter: Shawn Heisey
> Assignee: Shawn Heisey
> Priority: Major
> Labels: pull-request-available
> Attachments: SOLR-3284.patch
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> StreamingUpdateSolrServer eats exceptions thrown by lower level code, such as
> HttpClient, when doing adds. It may happen with other methods, though I know
> that query and deleteByQuery will throw exceptions. I believe that this is a
> result of the queue/Runner design. That's what makes SUSS perform better,
> but it means you sacrifice the ability to programmatically determine that
> there was a problem with your update. All errors are logged via slf4j, but
> that's not terribly helpful except with determining what went wrong after the
> fact.
> When using CommonsHttpSolrServer, I've been able to rely on getting an
> exception thrown by pretty much any error, letting me use try/catch to detect
> problems.
> There's probably enough dependent code out there that it would not be a good
> idea to change the design of SUSS, unless there were alternate constructors
> or additional methods available to configure new/old behavior. Fixing this
> is probably not trivial, so it's probably a better idea to come up with a new
> server object based on CHSS. This is outside my current skillset.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
