[
https://issues.apache.org/jira/browse/SOLR-11596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16235562#comment-16235562
]
Oleg Kalnichevski commented on SOLR-11596:
------------------------------------------
This is per RFC 2616 recommendation.
{noformat}
8.1.4 Practical Considerations
...
Clients that use persistent connections SHOULD limit the number of
simultaneous connections that they maintain to a given server. A
single-user client SHOULD NOT maintain more than 2 connections with
any server or proxy. A proxy SHOULD use up to 2*N connections to
another server or proxy, where N is the number of simultaneously
active users.
{noformat}
The restriction of the number of concurrent connections has been relaxed by RFC
7230 and removed in HttpClient 5.0
Oleg
> SolrJ clients -- create internal HttpClient objects with increased thread
> capability
> ------------------------------------------------------------------------------------
>
> Key: SOLR-11596
> URL: https://issues.apache.org/jira/browse/SOLR-11596
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: clients - java
> Affects Versions: 7.1
> Reporter: Shawn Heisey
> Priority: Minor
>
> The HttpClient object that various SolrClient implementations create has
> HttpClient's default per-destination thread limit of two. I'm not sure why
> they went with such a low default, but that's out of our hands. The low
> default makes default SolrClient objects that are thread-safe, but basically
> unable to handle more than two threads at the same time.
> Increasing this limit in user programs is very doable by creating a custom
> HttpClient object, but the amount of code required is fairly extensive.
> I think that when our client implementations create an HttpClient object,
> they should explicitly increase the thread limits to larger default values,
> and expose configuration knobs for those values in the fluent interface.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
