[
https://issues.apache.org/jira/browse/LUCENE-5310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808981#comment-13808981
]
Michael McCandless commented on LUCENE-5310:
--------------------------------------------
{quote}
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?
{quote}
I think that's an important feature, not a bug: it prevents merge
starvation.
Ie, if the indexing threads are producing segments faster than merging
can merge them then those indexing threads should be stalled so
merging can catch up.
It's true it won't see all threads that enter IW, but it will see the
threads that are responsible for making new segments, and those are
the ones that need to be paused when merging is falling behind.
{quote}
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.
{quote}
Maybe we could improve SMS so that it wouldn't block the
segment-producing threads until a 2nd merge is queued? (Today, it
blocks the producing threads as soon as another segment is written and
a merge is still running).
> 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]
