[
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: [email protected]
For additional commands, e-mail: [email protected]
