[
https://issues.apache.org/jira/browse/SOLR-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14585275#comment-14585275
]
Yonik Seeley commented on SOLR-7344:
------------------------------------
bq. You shouldn't deadlock with this approach - the request that can't get a
thread for it's type will simply time out on the queue
Ah right, if everything now has timeouts, then at least things will fail at
some point.
But I guess by that same logic we don't really even need separate queues any
more to prevent distributed deadlock. Of course we still want them. And
relying on timeouts to break distributed deadlocks would be a really
inefficient proposition (i.e. should not be used on queues with a low limit,
where limiting happens even when the system isn't overloaded).
bq. better than arbitrarily failing requests at some low level when the system
still has resources it could use.
{quote}
I don't agree with that. I think if a user wants that fine, but that by default
we should run within something comfortable like 500-300 threads or something,
and reject above that.
{quote}
300-500 threads is a ton (and we could rightly consider the system to be
overloaded beyond that point). I guess I'd still call this the "closer to
unbounded" queue if you disagree with the "effectively unbounded" thing. An
important point is that this queue should *not* be the same queue as one that
would have a desirable lower limit.
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.
You would not want an intermediate request from the streaming API to be taking
up one of those slots though, both due to (temporary) distributed deadlock and
inefficient resource utilization.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
