[
https://issues.apache.org/jira/browse/SOLR-10893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16086153#comment-16086153
]
Varun Thacker commented on SOLR-10893:
--------------------------------------
I'm going to start working on this again. Currently more inclined to keep it
part of a separate thread pool . That way we in the future when we have
different jetty thread pools we can make use of it
> 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: [email protected]
For additional commands, e-mail: [email protected]
