Solr WebApp wide Executor for better efficient management of threads , separating the logic in the thread from the launch of the same. ---------------------------------------------------------------------------------------------------------------------------------------
Key: SOLR-922 URL: https://issues.apache.org/jira/browse/SOLR-922 Project: Solr Issue Type: Improvement Components: clients - java Environment: Tomcat 6, JRE 6 Reporter: Kay Kay Priority: Minor For a different jira - when we were discussing bringing in parallelism through threads and using Executors - encountered a case of using a webapp wide Executor for reusing thread pools for better use of thread resources , instead of thread.start() . pros: Custom Request Handlers and other plugins to the Solr App server can use this Executor API to retrieve the executor and just submit the Runnable / Callable impls to get the job done while getting the benefits of a thread pool . This might be necessary as we continue to write plugins to the core architecture and centralizing the threadpools might make it easy to control / prevent global Executor objects across the codebase / recreating them locally ( as they might be expensive ). $ find . -name *.java | xargs grep -nr 'start()' | grep "}" ./contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/XPathEntityProcessor.java:377: }.start(); ./contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/DataImporter.java:368: }.start(); ./src/java/org/apache/solr/handler/SnapPuller.java:382: }.start(); ./src/java/org/apache/solr/handler/SnapShooter.java:52: }.start(); ./src/java/org/apache/solr/handler/ReplicationHandler.java:134: }.start(); ./src/common/org/apache/solr/common/util/ConcurrentLRUCache.java:112: }.start(); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.