[
https://issues.apache.org/jira/browse/SOLR-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14585348#comment-14585348
]
Yonik Seeley edited comment on SOLR-7344 at 6/15/15 12:40 AM:
--------------------------------------------------------------
bq. Good discussion. I hope we are still on track with this design ?
The general mechanism seems fine, yes.
But if this issue will also enable it by default, then the details still need
to be nailed down. What requests go to what queues, and which queues can be
safely lowered to limit concurrency and increase throughput, and which queues
need to be configured near upper bounds to work correctly.
Or we could split it up and limit this JIRA issue to the mechanism and punt
enabling with good defaults to another issue.
edit: or enable but have high limits for all queues before we figure out what
good defaults are (that should not be worse than the current scenario). I just
don't want to go backwards by committing something with bad defaults on a
promise that we'll figure out the right thing later.
was (Author: [email protected]):
bq. Good discussion. I hope we are still on track with this design ?
The general mechanism seems fine, yes.
But if this issue will also enable it by default, then the details still need
to be nailed down. What requests go to what queues, and which queues can be
safely lowered to limit concurrency and increase throughput, and which queues
need to be configured near upper bounds to work correctly.
Or we could split it up and limit this JIRA issue to the mechanism and punt
enabling with good defaults to another issue.
> 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]
