[
https://issues.apache.org/jira/browse/LUCENE-2840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979293#action_12979293
]
Michael McCandless commented on LUCENE-2840:
--------------------------------------------
bq. I think if you want to be super-generic, it's better to defer exact
threading to the user, instead of doing a one-size-fits-all solution. Else you
risk conjuring another ConcurrentMergeScheduler.
I think something like CMS (basically a custom ES w/ proper thread
prio/scheduling) will be necessary here.
Until Java can schedule threads the way an OS schedules processes we'll need to
emulate it ourselves.
You want long running queries (or, merges) to be gracefully down prioritized so
that new/fast queries (merges) finish quickly.
And you want searches (merges) to use the allowed concurrency fully.
> Multi-Threading in IndexSearcher (after removal of MultiSearcher and
> ParallelMultiSearcher)
> -------------------------------------------------------------------------------------------
>
> Key: LUCENE-2840
> URL: https://issues.apache.org/jira/browse/LUCENE-2840
> Project: Lucene - Java
> Issue Type: Sub-task
> Components: Search
> Reporter: Uwe Schindler
> Priority: Minor
> Fix For: 4.0
>
>
> Spin-off from parent issue:
> {quote}
> We should discuss about how many threads should be spawned. If you have an
> index with many segments, even small ones, I think only the larger segments
> should be separate threads, all others should be handled sequentially. So
> maybe add a maxThreads cound, then sort the IndexReaders by maxDoc and then
> only spawn maxThreads-1 threads for the bigger readers and then one
> additional thread for the rest?
> {quote}
--
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: [email protected]
For additional commands, e-mail: [email protected]
