[
https://issues.apache.org/jira/browse/LUCENE-2898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988540#action_12988540
]
Shai Erera commented on LUCENE-2898:
------------------------------------
Mike, now that you wait before you poll IW.getNextMerge, isn't there a risk CMS
pulled from IW all of its merges (say 1 + maxMergeCount) but there are no more
merges? So now the code will wait until one of the merges completes, before the
user gets back control (since it's CMS.merge(IW) that waits)?
> CMS merge throttling is not aggressive enough
> ---------------------------------------------
>
> Key: LUCENE-2898
> URL: https://issues.apache.org/jira/browse/LUCENE-2898
> Project: Lucene - Java
> Issue Type: Bug
> Components: Index
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 3.1, 4.0
>
>
> I hit this crab while working on the NRT benchmarker (in luceneutil).
> CMS today forcefully idles any incoming threads, when there are too many
> merges pending.
> This is the last line of defense that it has, since it also juggles thread
> priorities (and forcefully idles the biggest merges) to try to reduce the
> outstanding merge count.
> But when it cannot keep up it has no choice but to stall those threads
> responsible for making new segments.
> However, the logic is in the wrong place now -- the stalling happens after
> pulling the next merge from IW. This is poor because it means if you have N
> indexing threads, you allow max + N outstanding merges.
> I have a simple fix, which is to just move the stall logic to before we pull
> the next merge from IW.
--
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]
