[
https://issues.apache.org/jira/browse/SOLR-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221813#comment-13221813
]
Lance Norskog commented on SOLR-3197:
-------------------------------------
bq. The original rational was "do we really want to peg more than one CPU with
warmup while we are still serving live traffic?" But some people are using
pretty big boxes these days.
In this case 24 cores, tens of facet fields, hundreds of thousands of facets in
some fields.
Those few lines of code are the only multi-threaded code in SolrCore that I am
smart enough to understand.
bq. An alternative would be to use the CachedThreadPool as default as it makes
it possible to reuse cached threads
This task starts N long-lived threads and waits until they all finish. I think
the thread cache is useful when you have lots of short-lived threads.
> Allow firstSearcher and newSearcher listeners to run in multiple threads
> ------------------------------------------------------------------------
>
> Key: SOLR-3197
> URL: https://issues.apache.org/jira/browse/SOLR-3197
> Project: Solr
> Issue Type: Improvement
> Reporter: Lance Norskog
>
> SolrCore submits all listeners (firstSearcher and newSearcher) to a java
> ExecutorService, but uses a single-threaded one.
> line 965 in the trunk:
> {code}
> SolrCore.java around line 965: final ExecutorService searcherExecutor =
> Executors.newSingleThreadExecutor();
> line 1280 in the trunk:
> SolrCore.java around line 1280 runs first the, and then the first and new
> searchers, all with the searcherExecutor object created at line 965.
> Would it work if we changed this ExecutorService to a thread pool version?
> This seems like it should work:
> {code}
> java.util.concurrent.Executors.newFixedThreadPool(int nThreads, ThreadFactory
> threadFactory);
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
