lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kay Kay (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-922) Solr WebApp wide Executor for better efficient management of threads , separating the logic in the thread from the launch of the same.
Date Tue, 16 Dec 2008 21:06:44 GMT

    [ https://issues.apache.org/jira/browse/SOLR-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657162#action_12657162
] 

Kay Kay commented on SOLR-922:
------------------------------

Ok - I believe having a SolrCore specific Executor/ ExecutorService might work well fine as
I believe plugins that are SolrCoreAware can still make use of the same. 

The motivation is to prevent multiple Executor policies (/static objects especially ) locally
at each place where we need to launch threads or worse - not using them at all . 

> 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.


Mime
View raw message