[
https://issues.apache.org/jira/browse/SOLR-4449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583054#comment-13583054
]
philip hoy commented on SOLR-4449:
----------------------------------
Raintung, Agreed the strategy does use more threads, but that is unavoidable I
believe because work needs to be done concurrently. The two concurrent tasks
are firstly to await completed requests and optionally create new requests if
the request takes too long and secondly to send the request and accept the
response. If a request is made in the main thread then of course it will block
that thread so can't react if a request it sent previously in another thread
responds.
In the case where 100 requests are sent, if all is well then in will use 200
threads, if there are issues then no doubt servers will be zombied so it is
unlikely to cycle through all 3 shards for all 100 requests.
> Enable backup requests for the internal solr load balancer
> ----------------------------------------------------------
>
> Key: SOLR-4449
> URL: https://issues.apache.org/jira/browse/SOLR-4449
> Project: Solr
> Issue Type: New Feature
> Components: SolrCloud
> Reporter: philip hoy
> Priority: Minor
> Attachments: SOLR-4449.patch
>
>
> Add the ability to configure the built-in solr load balancer such that it
> submits a backup request to the next server in the list if the initial
> request takes too long. Employing such an algorithm could improve the latency
> of the 9xth percentile albeit at the expense of increasing overall load due
> to additional requests.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
