[
https://issues.apache.org/jira/browse/SOLR-8205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14972711#comment-14972711
]
Yonik Seeley edited comment on SOLR-8205 at 10/24/15 4:59 PM:
--------------------------------------------------------------
A downside to configuring an upper bound will be big update reorders (when that
upper bound is hit) and then undetected shard inconsistency as a result. That
update handler is used for different things too... both update streams (which
may be very long lived) and control messages (peersync? LIR?) and could lead to
starvation. I certainly wouldn't want to try and debug issues around that ;-)
was (Author: [email protected]):
A downside to configuring an upper bound will be big update reorders (when that
upper bound is hit) and then undetected shard inconsistency as a result. That
update handler is used for different things too... both update streams (which
may be very long lived) and hence could lead to starvation. I certainly
wouldn't want to try and debug issues around that ;-)
> Make UpdateShardHandler's thread pool configurable
> --------------------------------------------------
>
> Key: SOLR-8205
> URL: https://issues.apache.org/jira/browse/SOLR-8205
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Reporter: Shalin Shekhar Mangar
> Fix For: 5.4, Trunk
>
>
> Resource consumption under arbitrary query load can be limited with careful
> bound on maximumPoolSize in ShardHandlerFactory and appropriate timeouts but
> it is not possible to do the same for updates because of UpdateShardHandler
> uses an unbounded cached thread pool. This is a major problem, for example,
> when trying use SolrCloud as a service and attempting to guarantee SLAs.
> I propose to make the UpdateShardHandler's core/max thread pool size and
> thread keep alive time configurable. If we change the pool size to be
> bounded, does it make sense to make the queue size also configurable?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
