[
https://issues.apache.org/jira/browse/LUCENE-6197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14289988#comment-14289988
]
Michael McCandless commented on LUCENE-6197:
--------------------------------------------
bq. 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?
I singled out this case because it's the trigger that the merge threads pass
when they invoke CMS.merge after finishing their original merge.
I think it's dangerous to do the same logic on MergeTrigger.CLOSING: it would
mean that when you close IW, with waitForMerges=true, and there are backlog'd
merges, then we would drop them instead of letting them schedule and run.
Maybe another solution I could do here is to check Thread.currentThread() and
if that is one of our merge threads, skip the stalling (instead of checking the
MergeTrigger). Then we don't need to add MergeTrigger to maybeStall ... I'll
explore that.
> 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
> Priority: Blocker
> 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]
