[
https://issues.apache.org/jira/browse/SOLR-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14586370#comment-14586370
]
Yonik Seeley commented on SOLR-7344:
------------------------------------
bq. I don't agree. The first time you try to do a streaming api query that
requires enough recursion to use that many threads will fail and the user will
realize what is happening. I think this is better behavior!
I'm not sure you understand. If we have 2 queues, then 3 levels of requests is
enough to get into trouble same as today. All the threads come from the fact
that you have a lot of top-level requests... same as distributed search today.
It's not from a single request of some run-away query or something.
That's why we need (a) a separate queue for those types of requests that we can
configure with a higher limit.
The normal "internal query" pool we (or a user) may want to crank down to low
numbers for good throughput but with a high buffering to handle spikes. That
*must* be a different queue than the queue that can be called recursively.
But it really feels like you're just picking things out to disagree with, so
I'll stop now and use a veto later if necessary to prevent a bad default from
being committed.
> Allow Jetty thread pool limits while still avoiding distributed deadlock.
> -------------------------------------------------------------------------
>
> Key: SOLR-7344
> URL: https://issues.apache.org/jira/browse/SOLR-7344
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Reporter: Mark Miller
> Attachments: SOLR-7344.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
