[
https://issues.apache.org/jira/browse/SOLR-3284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13255433#comment-13255433
]
Sami Siren commented on SOLR-3284:
----------------------------------
What are the operations/error situations where you are not seeing an Exception
when you expect one?
By default the ConcurrentUpdateSolrServer (StreamingUpdateSolrServer) just logs
the exceptions from updates but you can override this functionality:
{code}
SolrServer server = new
ConcurrentUpdateSolrServer("http://127.0.0.1:8983/solr";, 1, 1){
public void handleError(Throwable ex) {
//do something with the Throwable here
System.out.println("Something wrong!" + ex.getMessage());
}
};
server.add(new SolrInputDocument());
{code}
The current exception reporting is pretty limited and it is impossible to see
which operation triggered the exception but such improvements should be done in
separate issues.
> 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
> Reporter: Shawn Heisey
>
> 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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
