[
https://issues.apache.org/jira/browse/SOLR-13570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16870551#comment-16870551
]
Cao Manh Dat commented on SOLR-13570:
-------------------------------------
This problem can be solved by removing all call in *Cmd
{code}
ocmh.shardHandlerFactory.getShardHandler(ocmh.overseer.getCoreContainer().getUpdateShardHandler().getDefaultHttpClient())
{code}
which is using Apache HttpClient by
{{ocmh.shardHandlerFactory.getShardHandler()}} to use {{Http2SolrClient}}.
It makes sense now since we are moved to Http/2 so we don't have to use a
dedicated client for this kind of tasks. What do you think
[~markrmil...@gmail.com]?
> Unable to control timeout for requests from Overseer to other nodes
> -------------------------------------------------------------------
>
> Key: SOLR-13570
> URL: https://issues.apache.org/jira/browse/SOLR-13570
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Cao Manh Dat
> Assignee: Cao Manh Dat
> Priority: Major
>
> All Overseer requests uses {{UpdateShardHandler.httpClient}}, so in theory we
> should be able to control timeout by setting {{distribUpdateConnTimeout}} in
> {{solr.xml}}. Since HttpClient was configured with timeout from
> {{distribUpdateConnTimeout}}
> It used to work but since SOLR-11004, we hardcoded the timeout in
> SolrClientBuilder.socketTimeoutMillis = 120000, therefore any HttpSolrClient
> without specify {{withSocketTimeout()}} will have timeout = 120000. We
> basically ignore the timeout set to HttpClient.
> For long async tasks like BACKUP/RESTORE, 2 minutes is not enough and users
> will frequently encountering timeout on these calls.
--
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
