[
https://issues.apache.org/jira/browse/SOLR-10893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Varun Thacker closed SOLR-10893.
--------------------------------
Resolution: Not A Problem
In 7.0 and master when we create a HttpSolrClient and CloudSolrClient without
providing a default httpclient both max connections and max connections per
host is set to 10k . This was not the case in the 6.x line of code though.
> SolrClients used by streaming should support setting max connections
> --------------------------------------------------------------------
>
> Key: SOLR-10893
> URL: https://issues.apache.org/jira/browse/SOLR-10893
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Varun Thacker
>
> All the streaming expressions , SQL queries use a common SolrClientCache for
> issuing the underlying queries.
> Today we use a default HttpClient while creating this which means if we
> running many parallel stream queries or deeply nested queries we can exhaust
> this.
> We should allow users to set higher defaults for max connections, max
> connections per route etc.
> Today since we use a default HttpClient does Streaming work with auth enabled
> or in kerberos mode? I'll look into this and confirm.
> My idea is we could probably refactor in a way that CoreContainer keeps an
> object of SolrClientCache which uses the httpclient that is currently used
> for searches ( HttpShardHandlerFactory ) . This means we don't need to
> introduce more settings .
> Thoughts? Do we want to keep search threads and streaming threads part of
> separate pools?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
