[
https://issues.apache.org/jira/browse/SOLR-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221715#comment-13221715
]
Yonik Seeley commented on SOLR-3197:
------------------------------------
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.
Beware some startup code that expects a single threaded executor though - we
can't just switch that w/o other code changes!
See the SolrCore constructor for more details.
> 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
