[
https://issues.apache.org/jira/browse/LUCENE-6197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14290007#comment-14290007
]
Robert Muir commented on LUCENE-6197:
-------------------------------------
{quote}
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.
{quote}
OK, thank you, I would not have asked the question if the logic was coded that
way, as I was expecting something like that and confused about MergeTrigger
logic and if/why that really encapsulates all cases.
> 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]
