[
https://issues.apache.org/jira/browse/SOLR-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15705521#comment-15705521
]
David Smiley commented on SOLR-3284:
------------------------------------
It's telling that nowadays, internally in Solr there are actually 2 subclasses
of ConcurrentUpdateSolrClient who both exist to handle errors:
SafeConcurrentUpdateSolrClient (in morphlines) and
ErrorReportingConcurrentUpdateSolrClient (defined within and returned by
StreamingSolrClients, used by SolrCmdDistributor used by
DistributedUpdateProcessor). And note also that all constructors are of CUSC
are deprecated even though the only way to actually implement handleError by a
user implies you need to use them since the Builder doesn't expose configuring
error handling.
IMO the default behavior of CUSC should be basically just like
SafeConcurrentUpdateSolrClient so that users see problems readily. Perhaps
also check & throw in request(). StreamingSolrClients can override to do it's
special handling.
> StreamingUpdateSolrServer 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
> Attachments: SOLR-3284.patch
>
>
> 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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
