[ 
https://issues.apache.org/jira/browse/SOLR-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18095344#comment-18095344
 ] 

Serhiy Bzhezytskyy commented on SOLR-3284:
------------------------------------------

Thanks! Opened #4632.

> 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: 10m
>  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]

Reply via email to