[ https://issues.apache.org/jira/browse/LUCENE-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923665#action_12923665 ]
Michael McCandless commented on LUCENE-2618: -------------------------------------------- bq. Just want to point out that calling maybeMerge is as explicit as calling optimize. But: apps don't normally call maybeMerge? This is typically called within IW, eg on segment flush. I mean, it is public so apps can call it, but I expect very few do (vs optimize which apps use alot). It's the exception not the rule... I guess I feel that close should try to close quickly -- an app would not expect close to randomly take a long time (it's already bad enough since a large merge could be in process...). So, allowing other merges to start up, which could easily be large merges since they are follow-on ones, would make that worse. Alternatively, we could define the semantics of close as being allowed to prevent a running optimize from actually completing? Then we'd have to change this test, eg to call .waitForMerges before close. > Intermittent failure in 3.x's backwards TestThreadedOptimize > ------------------------------------------------------------ > > Key: LUCENE-2618 > URL: https://issues.apache.org/jira/browse/LUCENE-2618 > Project: Lucene - Java > Issue Type: Bug > Components: Index > Reporter: Michael McCandless > Fix For: 3.1, 4.0 > > Attachments: LUCENE-2618.patch > > > Failure looks like this: > {noformat} > [junit] Testsuite: org.apache.lucene.index.TestThreadedOptimize > [junit] Testcase: > testThreadedOptimize(org.apache.lucene.index.TestThreadedOptimize): FAILED > [junit] null > [junit] junit.framework.AssertionFailedError: null > [junit] at > org.apache.lucene.index.TestThreadedOptimize.runTest(TestThreadedOptimize.java:125) > [junit] at > org.apache.lucene.index.TestThreadedOptimize.testThreadedOptimize(TestThreadedOptimize.java:149) > [junit] at > org.apache.lucene.util.LuceneTestCase.runBare(LuceneTestCase.java:253) > {noformat} > I just committed some verbosity so next time it strikes we'll have more > details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org