[
https://issues.apache.org/jira/browse/LUCENE-6197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14289916#comment-14289916
]
Robert Muir commented on LUCENE-6197:
-------------------------------------
Is there a way you can elaborate on the trigger == MergeTrigger.MERGE_FINISHED?
I don't understand why its the only case where we do this. why not CLOSING too,
etc?
> ConcurrentMergeScheduler should not stall its own merge threads!
> ----------------------------------------------------------------
>
> Key: LUCENE-6197
> URL: https://issues.apache.org/jira/browse/LUCENE-6197
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Fix For: 5.0, Trunk, 5.1
>
> Attachments: LUCENE-6197.patch
>
>
> http://build-eu-00.elasticsearch.org/job/lucene_trunk_linux_java8_64_analyzers/25834
> uncovered this issue.
> I accidentally introduced this with auto-IO-throttle (LUCENE-6119)
> ... the CMS.maybeStall method, which is supposed to block "segment
> producing" threads so indexing slows down when merges cannot keep up,
> can now sometimes block its own merge threads. This happens when the merge
> thread re-invokes CMS.merge after it finishes, so new merges can kick
> off.
> This is really silly, since merge threads are not segment producers,
> but rather the "messengers", spawned by the true segment producers,
> so CMS should not shoot the messenger here.
> I think it's also possible this could lead to deadlock in CMS, but I'm
> not certain, and I couldn't provoke it.
> I'd like to fix this for 5.0 because it was first introduced in 5.0
> and not yet released...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
