You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Roger Lehmann (JIRA)" <ji...@apache.org> on 2019/04/03 11:15:00 UTC
[jira] [Commented] (SOLR-11208) Usage SynchronousQueue in Executors
prevent large scale operations
[ https://issues.apache.org/jira/browse/SOLR-11208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16808615#comment-16808615 ]
Roger Lehmann commented on SOLR-11208:
--------------------------------------
A quick and helpful workaround of this design flaw would be to make the maximum amount of threads available to the MDCAwareThreadPool configurable in the Solr config.
It is currently preventing me from using SolrCloud 7.7.1 in an AWS auto scaling group where instances are added and deleted dynamically.
I'm unfortunately not fit to do these changes myself, anyone up to that? Would be great, thanks!
> Usage SynchronousQueue in Executors prevent large scale operations
> ------------------------------------------------------------------
>
> Key: SOLR-11208
> URL: https://issues.apache.org/jira/browse/SOLR-11208
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 6.6
> Reporter: Björn Häuser
> Priority: Major
>
> I am not sure where to start with this one.
> I tried to post this already on the mailing list: https://mail-archives.apache.org/mod_mbox/lucene-solr-user/201708.mbox/%3c48C49426-33A2-4D79-AE26-A4515B8F834E@gmail.com%3e
> In short: the usage of a SynchronousQueue as the workQeue prevents more tasks than max threads.
> For example, taken from OverseerCollectionMessageHandler:
> {code:java}
> ExecutorService tpe = new ExecutorUtil.MDCAwareThreadPoolExecutor(5, 10, 0L, TimeUnit.MILLISECONDS,
> new SynchronousQueue<>(),
> new DefaultSolrThreadFactory("OverseerCollectionMessageHandlerThreadFactory"));
> {code}
> This Executor is used when doing a REPLACENODE (= ADDREPLICA) command. When the node has more than 10 collections this will fail with the mentioned java.util.concurrent.RejectedExecutionException.
> I am also not sure how to fix this. Just replacing the queue with a different implementation feels wrong to me or could cause unwanted side behaviour.
> Thanks
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org