[ https://issues.apache.org/jira/browse/LUCENE-6197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael McCandless resolved LUCENE-6197. ---------------------------------------- Resolution: Fixed > 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, 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org