[
https://issues.apache.org/jira/browse/SOLR-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657432#action_12657432
]
Kay Kay commented on SOLR-922:
------------------------------
| But the risk is that we will never know that which consumer is eating up the
threads and some other consumers will be starved for threads. These things
become hard to debug.
Sure. Suppose - we have multiple plugins to the Solr system and consumers are
starved for threads, (assuming a uniform ExecutorService) , we can load the
number of threads in the thread pool configurable from a property in the Solr
System or change the policy of creation ( FixedSize / CachedPools etc. ) at one
point and experiment with the same.
On the other hand - having local ExecutorServices for modules would mean
optimizing the problem locally in that module / creating multiple static thread
pools , adding to the global memory usage quickly when in reality they cannot
be used interchangeably ( A local ExecutorService in DIH - would probably not
be accessible to SnapPuller, say). Having a central control over the resources
might be more beneficial in this case.
> 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.
