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