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] Updated: (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 Fri, 19 Dec 2008 23:18:44 GMT

     [ https://issues.apache.org/jira/browse/SOLR-922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Kay Kay updated SOLR-922:
-------------------------

    Attachment: ExecServiceTest.java

Profiling program comparing ExecutorService against Threads when launching. 

Approximately ~80% gain in ExecutorService to launch Thread objects (put them into the queue).


> 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
>         Attachments: ExecServiceTest.java, SOLR-922.patch
>
>
> 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