[
https://issues.apache.org/jira/browse/SOLR-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14585289#comment-14585289
]
Mark Miller commented on SOLR-7344:
-----------------------------------
bq. 300-500 threads is a ton
I meant 300-5000. I'm not tied to any number. I don't think 300 threads max for
an app is high at all. I'd be very happy if that was Solr's starting point.
bq. I guess I'd still call this the "closer to unbounded" queue if you disagree
with the "effectively unbounded" thing.
I think it's fuzzy. I know if a server won't use more than 1k threads by
default I'm happy and otherwise I'm less happy. I know I'd also like to be able
to configure a max of 25 or 50 threads. I'd want a default that wasn't crazy
(like I think 10k is) but no so low as to stop normal load and use cases. Where
is that number? I don't know. I do know it's not 10k.
bq. But I guess by that same logic we don't really even need separate queues
any more to prevent distributed deadlock.
Right, we can have these types of timeouts anyway - but this is nicer.
bq. For example, one could reasonably configure the Internal_Querying queue
size to be something like 16 or 32 for better use of resources and higher
throughput.
Yes, this is what I'm after - it would be great to be able to drop things way
down and still get *reasonable* behavior.
> 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]
