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

Mark Miller commented on SOLR-7951:
-----------------------------------

For the new test, isn't this particular cause still supposed to actually say No 
live SolrServers available to handle this request?

The root problem is a socket timeout exception to that server in the test - 
when we have connection problems, we try the other server options and finally 
return 'no live solr servers' with the root cause.

We should avoid that message only when the problem is not connection related.

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

Reply via email to