[
https://issues.apache.org/jira/browse/LUCENE-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12777645#action_12777645
]
Simon Willnauer commented on LUCENE-2063:
-----------------------------------------
One of the issues with this is that the code depends on Thread instead of
Runnable / Callable. I have looked into this class too and figured that simply
exchanging the merger threads with runnables would not work.
A way of doing this is to subclass ExecutorService where we can expose the
required functionality on a pooled basis.
Beside this I'm not sure if there is any benefit performance / resource wise as
merge threads are not needed as frequently as other threads. Threadpools make a
lot of sense once you use threads frequently but keeping those merge threads
around might not be required. Not sure if this is really needed though.
simon
> Use thread pool in ConcurrentMergeScheduler
> -------------------------------------------
>
> Key: LUCENE-2063
> URL: https://issues.apache.org/jira/browse/LUCENE-2063
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Index
> Affects Versions: 2.9.1
> Reporter: Jason Rutherglen
> Priority: Minor
> Fix For: 3.1
>
>
> Currently it looks like CMS creates a new thread object for each
> merge, which may not be expensive anymore on Java5+ JVMs,
> however we can fairly simply implement the Java5 thread pooling.
> Also I'm thinking we may be interested in using thread pools for
> other tasks in IndexWriter (such as LUCENE-2047 performing
> deletes in the background).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
