[
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: [email protected]
For additional commands, e-mail: [email protected]
