[
https://issues.apache.org/jira/browse/LUCENE-2898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988595#action_12988595
]
Shai Erera commented on LUCENE-2898:
------------------------------------
So if the user allows for N max-merges in CMS, and MP returns N merges to be
executed, then this is fine. If however MP returns N + 1 merges, then CMS will
register N + 1 merges, and then stall? I'm asking because the while() checks
for mergeThreadCount() >= 1 + maxMergeCount.
Before your changes, at most maxMergeCount merges could be registered, while
now the code allows for maxMergeCount + 1? I'm confused.
And my question I think is stil valid - what if CMS waits for nothing - meaning
after wait() finishes, IW.getNextMerge() returns null? The user thread will be
blocked until then, even though no more merges are 'pending'?
Perhaps I'm just confused though ... :)
> 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]
