You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Marc Morissette (JIRA)" <ji...@apache.org> on 2018/07/13 00:44:00 UTC
[jira] [Updated] (SOLR-12550) ConcurrentUpdateSolrClient doesn't
respect timeouts for commits and optimize
[ https://issues.apache.org/jira/browse/SOLR-12550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marc Morissette updated SOLR-12550:
-----------------------------------
Description:
We're in a situation where we need to optimize some of our collections. These optimizations are done with waitSearcher=true as a simple throttling mechanism to prevent too many collections from being optimized at once.
We're seeing these optimize commands return without error after 10 minutes but well before the end of the operation. Our Solr logs show errors with socketTimeout stack traces. Setting distribUpdateSoTimeout to a higher value has no effect.
See the links section for my patch.
It turns out that ConcurrentUpdateSolrClient delegates commit and optimize commands to a private HttpSolrClient but fails to pass along its builder's timeouts to that client.
was:
We're in a situation where we need to optimize some of our collections. These optimizations are done with waitSearcher=true as a simple throttling mechanism to prevent too many collections from being optimized at once.
We're seeing these optimize commands return without error after 10 minutes but well before the end of the operation. Our Solr logs show errors with socketTimeout stack traces. Setting distribUpdateSoTimeout to a higher value has no effect.
It turns out that ConcurrentUpdateSolrClient delegates commit and optimize commands to a private HttpSolrClient but fails to pass along its builder's timeouts to that client.
Environment:
[~elyograg] I am going to assume you didn't see that a patch with a unit test is attached to this bug (It's in the links section. It looks Github has stopped adding comments when a new pull request is detected).
Also, maybe I wasn't clear in my description but we don't use ConcurrentUpdateSolrClient in our client code. The issue is in SolrCloud itself where timeouts may occur in the ConcurrentUpdateSolrClient Solr uses to relay commit and optimize commands to its shards.
> ConcurrentUpdateSolrClient doesn't respect timeouts for commits and optimize
> ----------------------------------------------------------------------------
>
> Key: SOLR-12550
> URL: https://issues.apache.org/jira/browse/SOLR-12550
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Environment: [~elyograg] I am going to assume you didn't see that a patch with a unit test is attached to this bug (It's in the links section. It looks Github has stopped adding comments when a new pull request is detected).
> Also, maybe I wasn't clear in my description but we don't use ConcurrentUpdateSolrClient in our client code. The issue is in SolrCloud itself where timeouts may occur in the ConcurrentUpdateSolrClient Solr uses to relay commit and optimize commands to its shards.
> Reporter: Marc Morissette
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We're in a situation where we need to optimize some of our collections. These optimizations are done with waitSearcher=true as a simple throttling mechanism to prevent too many collections from being optimized at once.
> We're seeing these optimize commands return without error after 10 minutes but well before the end of the operation. Our Solr logs show errors with socketTimeout stack traces. Setting distribUpdateSoTimeout to a higher value has no effect.
> See the links section for my patch.
> It turns out that ConcurrentUpdateSolrClient delegates commit and optimize commands to a private HttpSolrClient but fails to pass along its builder's timeouts to that client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org