[ 
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to