[
https://issues.apache.org/jira/browse/LUCENE-6197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14290646#comment-14290646
]
ASF subversion and git services commented on LUCENE-6197:
---------------------------------------------------------
Commit 1654533 from [~mikemccand] in branch 'dev/trunk'
[ https://svn.apache.org/r1654533 ]
LUCENE-6197: CMS should not stall its own merge threads
> 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
