[ 
https://issues.apache.org/jira/browse/SOLR-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14585270#comment-14585270
 ] 

Mark Miller commented on SOLR-7344:
-----------------------------------

bq. We don't want 10K threads today... we have to have it (a high limit) or 
we'll get into distributed deadlock. 

Yes, though these days, we have default connection timeouts and it should 
actually make progress (the timeouts are very long though).

bq. better than arbitrarily failing requests at some low level when the system 
still has resources it could use.

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. I'd way rather Jetty was friendly with the system by 
default and we didn't have the thread storms we can see now. To me, that is the 
point of this issue - reasonable thread limits, reject stuff that breaks them, 
allow a user to configure limits as high as they want. That's just a much nicer 
system IMO.

bq. it just means that we can't put a safe bound on it without risking 
distributed deadlock.

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 and we can deny the request and 
alert the user they are using above normal resources and if they want to up the 
limits fine, but by default we avoid creating shit loads of threads.

> 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]

Reply via email to