[
https://issues.apache.org/jira/browse/SOLR-10893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16050602#comment-16050602
]
Varun Thacker commented on SOLR-10893:
--------------------------------------
bq. Thoughts? Do we want to keep search threads and streaming threads part of
separate pools?
I am currently inclined to use the same httpclient that is used in the
HttpShardHandlerFactory.
Even if we have separate thread pools for httpShardHandlerFactory and streaming
, a user cannot limit parallel analytic queries by reducing the thread pool as
they all come from the same jetty thread pool? Maybe it would be part of
SOLR-7344 or can be separate after that issue get's committed?
> 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]
