[
https://issues.apache.org/jira/browse/LUCENE-5310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13982363#comment-13982363
]
Michael McCandless commented on LUCENE-5310:
--------------------------------------------
bq. one thing that jumps out is that you still have no way to just return if
the scheduler is busy or the stall limit is reached. Maybe we should just do
something like this:
OK I'll try to get that working ... basically, if too many merges are running,
don't pull a new one from IW and optionally don't stall (we'll still stall by
default). It's a bit tricky because you don't want to try to stall unless
there is another merge wanting to run. Ie, when maxMergeCount=2, if there are
2 merges already running but no new merge is pending, we shouldn't try to
stall. But I think I can make something work ... I'll give it a shot.
> 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.9, 5.0
>
> Attachments: LUCENE-5310.patch, LUCENE-5310.patch, LUCENE-5310.patch,
> LUCENE-5310.patch, 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.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
