[
https://issues.apache.org/jira/browse/SOLR-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14707402#comment-14707402
]
Elaine Cario commented on SOLR-7951:
------------------------------------
[~eribeiro], Well, you got me there, I was asking myself the same question,
because I had it both ways (returning SolrException, and casting it to
SolrServerException), and I couldn't figure out why the compiler or the runtime
wasn't complaining, so I decided to go with the cast in case something
downstream might complain about SolrException coming out of a method that threw
a SolrServerException. However, as I've pondered this, I think it is because
SolrException (or RemoteSolrException) are descended from RuntimeException, so
you can throw those without needing to declare them. So I think you are right,
it is more proper to not cast it. I will test this some more next week to be
absolutely sure. I can also add appropriate comments around this.
> LBHttpSolrClient wraps ALL exceptions in "No live SolrServers available to
> handle this request" exception, even usage errors
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-7951
> URL: https://issues.apache.org/jira/browse/SOLR-7951
> Project: Solr
> Issue Type: Bug
> Components: SolrJ
> Affects Versions: 5.2.1
> Reporter: Elaine Cario
> Priority: Minor
> Attachments: SOLR-7951-4.x.patch, SOLR-7951.patch
>
>
> We were experiencing many "No live SolrServers available to handle this
> request" exception, even though we saw no outages with any of our servers.
> It turned out the actual exceptions were related to the use of wildcards in
> span queries (and in some cases other invalid queries or usage-type issues).
> Traced it back to LBHttpSolrClient which was wrapping all exceptions, even
> plain SolrExceptions, in that outer exception.
> Instead, wrapping in the out exception should be reserved for true
> communication issues in SolrCloud, and usage exceptions should be thrown as
> is.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
