You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Shawn Heisey (JIRA)" <ji...@apache.org> on 2013/04/19 19:15:16 UTC
[jira] [Commented] (SOLR-3284) StreamingUpdateSolrServer swallows
exceptions
[ https://issues.apache.org/jira/browse/SOLR-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13636619#comment-13636619 ]
Shawn Heisey commented on SOLR-3284:
------------------------------------
I think that having optional error reporting built into in the concurrent class is important, even if it cannot tell you which of your recent updates failed. Does anyone think my patch is a good first step, should I try another approach, or is this whole idea doomed?
I am not planning to close this issue at this time, but this comment is part of an effort to close old issues that I have reported. Search tag: elyograg2013springclean
> 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
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org