[ https://issues.apache.org/jira/browse/SOLR-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14706798#comment-14706798 ]
Mark Miller commented on SOLR-7951: ----------------------------------- Thanks for looking at this! I suspect the problem is around {code} // we retry on 404 or 403 or 503 or 500 // unless it's an update - then we only retry on connect exception {code} Do you know what the http code for the response was? Unfortunately, I'm not sure we can easily differentiate between a response we should retry or that is likely to get the same result on a retry. If this is the case, the above patch looks like a possible solution, but we probably want to add some comments to help future devs understand what happened here. We also want to make sure we are covering the following case correctly: {code} catch (SolrServerException e) { Throwable rootCause = e.getRootCause(); if (!isUpdate && rootCause instanceof IOException) { ex = (!isZombie) ? addZombie(client, e) : e; } else if (isUpdate && rootCause instanceof ConnectException) { ex = (!isZombie) ? addZombie(client, e) : e; } else { throw e; } {code} > 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