[
https://issues.apache.org/jira/browse/SOLR-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-3284:
-------------------------------
Summary: ConcurrentUpdateSolrClient swallows exceptions (was:
StreamingUpdateSolrServer swallows exceptions)
bq. It's not a bad idea to offer the option of trying to quit on the first
error. I'd make it a required construction param.
+1 to make error handling a required param. Although a 'false' setting is
dubious... if you do that then... do you really want no errors back? Or is
'false' supposed to be, false and provide your own error callback? Perhaps
make the error handler a lambda and no boolean flag. If you pass a null lambda
then you get the behavior of throwing as soon as we can (as seen in
SafeConcurrentUpdateClient). If lambda is non-null then it's invoked.
Furthermore, the CUSC instance might have setErrorIfUnset & getError methods
for possible use by a custom lambda.
bq. Most users that I've seen that want to do this though, want to count on
updates stopping after the first fail, so you can reason about how to handle
the situation reasonably, but you can actually end up with a few updates beyond
that in, so it's not as great as it sounds even when you do want that kind of
behavior.
We can address this through documentation. In particular, document that
blockUntilFinished() (or trigging it indirectly via a commit or similar) is
the only way to ensure the documents you've sent have no error.
> 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
> 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]
