lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomás Fernández Löbbe (JIRA) <>
Subject [jira] [Commented] (SOLR-11881) Connection Reset Causing LIR
Date Tue, 08 May 2018 04:10:00 GMT


Tomás Fernández Löbbe commented on SOLR-11881:

I updated the CR with a new patch. Added a test for minRf, but this is more deeply tested
in ReplicationFactorTest (that test now takes longer because of the retries. I'm thinking
in either making the wait time configurable or modify it for test purposes only). ReplicationFactorTest
is marked as {{@BadApple}} pointing to SOLR-6944, this retry logic will probably fix that
one. I haven't seen failures of that test so far.
There is one nocommit in the code, I'm wondering if we want to keep the retries for DBQs.
I'm thinking in setting the retry count for DBQs to 0, since those are not versioned AFAIK.
Another thing I noticed is that we sleep after each error retried (so if we need to retry
two requests to two hosts, we sleep before the first request, and sleep before the second
one). This seems odd, I think we want to sleep before retrying a batch of errors. I won't
be changing this here though, I'll create a new Jira for that.
I'll be running some tests with the current patch, feel free to review and let me know if
you have any thoughts

> Connection Reset Causing LIR
> ----------------------------
>                 Key: SOLR-11881
>                 URL:
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Varun Thacker
>            Assignee: Varun Thacker
>            Priority: Major
>         Attachments: SOLR-11881-SolrCmdDistributor.patch, SOLR-11881.patch, SOLR-11881.patch
> We can see that a connection reset is causing LIR.
> If a leader -> replica update get's a connection like this the leader will initiate
> {code:java}
> 2018-01-08 17:39:16.980 ERROR (qtp1010030701-468988) [c:collection s:shardX r:core_node56
collection_shardX_replicaY] o.a.s.u.p.DistributedUpdateProcessor Setting up to try to start
recovery on replica https://host08.domain:8985/solr/collection_shardX_replicaY/
> Connection reset
>         at
>         at
>         at
>         at
>         at
>         at
>         at
>         at
>         at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(
>         at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(
>         at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(
>         at
>         at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(
>         at org.apache.http.impl.client.DefaultRequestDirector.execute(
>         at org.apache.http.impl.client.AbstractHttpClient.doExecute(
>         at org.apache.http.impl.client.CloseableHttpClient.execute(
>         at org.apache.http.impl.client.CloseableHttpClient.execute(
>         at org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.sendUpdateStream(
>         at org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$
>         at org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(
>         at java.util.concurrent.ThreadPoolExecutor$
>         at
> {code}
> From Mark says "On a heavy working SolrCloud
cluster, even a rare response like this from a replica can cause a recovery and heavy cluster
disruption" .
> Looking at SOLR-6931 we added a http retry handler but we only retry on GET requests.
Updates are POST requests {{ConcurrentUpdateSolrClient#sendUpdateStream}}
> Update requests between the leader and replica should be retry-able since they have been

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message