[
https://issues.apache.org/jira/browse/SOLR-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13221539#comment-13221539
]
Tommaso Teofili commented on SOLR-3197:
---------------------------------------
An alternative would be to use the CachedThreadPool as default as it makes it
possible to reuse cached threads (see
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/Executors.html#newCachedThreadPool()
)
> 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
