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.
