[jira] [Commented] (SOLR-3284) StreamingUpdateSolrServer swallows exceptions

["Mark Miller (JIRA)" <ji...@apache.org>]

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

Mark Miller commented on SOLR-3284:
-----------------------------------

You can use those hacks for specific use cases, but the only great solution for the general user client is really doing the work of efficiently returning error information for what could be tons of failed updates. 

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. 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. 



> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org