[
https://issues.apache.org/jira/browse/SOLR-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657677#action_12657677
]
Kay Kay commented on SOLR-922:
------------------------------
| But, the problem is that means defining an extra API and may be having an
extra configuration in say solrconfig.xml
Selecting the number of threads in the thread pools / specifying the queuing
policy for an even distribution of tasks , are some of the various
customizations that could be implemented for the ExecutorService
implementation. Since DIH and other parts of the solr application server live
in the same jvm process - I am not sure why we would like to exclude the same
since that would mean multiple resource managers ( thread pools ) in the same
process - that would be hard to change / modify if we encounter an
OutOfMemoryError (very much possible when there are multiple ExecutorService
impls locally ) etc.
> 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.
