[
https://issues.apache.org/jira/browse/SOLR-6944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14352051#comment-14352051
]
Alan Woodward commented on SOLR-6944:
-------------------------------------
I'm pretty sure this is due to stale connections (it generally occurs on the
first request after a Jetty has shutdown and then been restarted). There are
two places that need fixing:
* in HttpSolrClient - we should always call
ClientConnectionManager.closeExpiredConnections() if we get a
NoHttpResponseException, whether or not we retry (see SOLR-7203)
* in CloudSolrClient. We have a couple of options here: call
closeExpiredConnections() in a background thread (we already have an
executorservice here, so we can just use that), or alternatively call it
whenever there's a change in the cluster state. I quite like the latter idea -
it would be useful to have a generic 'register a callback that gets called
whenever the cluster state changes' API on ZkStateReader, and CloudSolrClient
could just use that.
> ReplicationFactorTest and HttpPartitionTest both fail with
> org.apache.http.NoHttpResponseException: The target server failed to respond
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-6944
> URL: https://issues.apache.org/jira/browse/SOLR-6944
> Project: Solr
> Issue Type: Test
> Reporter: Mark Miller
> Assignee: Mark Miller
> Attachments: SOLR-6944.patch
>
>
> Our only recourse is to do a client side retry on such errors. I have some
> retry code for this from SOLR-4509 that I will pull over here.
--
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
