[
https://issues.apache.org/jira/browse/LUCENE-5310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808196#comment-13808196
]
Simon Willnauer commented on LUCENE-5310:
-----------------------------------------
bq. This blocking in SMS is by design: SMS stalls any indexing threads while
merges are running; if you want concurrency you should use CMS?
Really, I mean this makes no sense at all. Ie. you have a merge running and you
index that means you will block all threads that might trigger a merge until
all pending merges are done? I think this is a bug! Really this interface says
only that is will do no merges concurrently that's it. You wanna use calling
threads for merging use SMS you don't wanna do that use CMS.
bq. CMS, also, needs to see all threads, because it (by design) stalls incoming
index threads when there are too many merges running.
that is another bug IMO. It's not the concern of the MS to block threads since
it might not even see all of them? The MS should take care of when merges need
to be scheduled stalling indexing threads it the DocWriters concern?
> Merge Threads unnecessarily block on SerialMergeScheduler
> ---------------------------------------------------------
>
> Key: LUCENE-5310
> URL: https://issues.apache.org/jira/browse/LUCENE-5310
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/index
> Affects Versions: 4.5, 5.0
> Reporter: Simon Willnauer
> Priority: Minor
> Fix For: 4.6, 5.0
>
> Attachments: LUCENE-5310.patch, LUCENE-5310.patch
>
>
> I have been working on a high level merge multiplexer that shares threads
> across different IW instances and I came across the fact that
> SerialMergeScheduler actually blocks incoming thread is a merge in going on.
> Yet this blocks threads unnecessarily since we pull the merges in a loop
> anyway. We should use a tryLock operation instead of syncing the entire
> method?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
