Reporter: Michael McCandless
Assignee: Michael McCandless
Priority: Minor
Fix For: 2.3
Attachments: LUCENE-1018.patch
The TestConcurrentMergeScheduler throws intermittant exceptions that
do not result in a test failure.
The exception
Chris Hostetter [EMAIL PROTECTED] wrote:
: But it'd be nice to do this across the board, ie, for any junit test
: if one of CMS's threads (or, threads launched elsewhere) hits an
: unhandled exception, fail the testcase that's currently running.
: I'll dig and see if there's some central
OK, I think I found one possibility here. With ant's junit task, you
can define a custom formatter implementing this interface:
org.apache.tools.ant.taskdefs.optional.junit.JUnitResultFormatter
That interface has a method endTestSuite that is invoked once at the
end of all the test cases.
Mike,
Would it work to have a common LuceneTestCase base class that could
do that check and fail() in tearDown?
Erik
On Oct 4, 2007, at 5:31 AM, Michael McCandless wrote:
OK, I think I found one possibility here. With ant's junit task, you
can define a custom formatter
Indeed this will work! I was unsure whether you could fail() a test
inside tearDown() but it seems to work fine -- I just tested it.
Only downside is a mass replacement of all extends TestCase with
extends LuceneTestCase (but that's a one time cost, now), and making
sure tearDown() always calls
intermittant exceptions in TestConcurrentMergeScheduler
---
Key: LUCENE-1018
URL: https://issues.apache.org/jira/browse/LUCENE-1018
Project: Lucene - Java
Issue Type: Bug
and also a few
other small issues and adding more verbosity when infoStream is set.
I plan to commit in a few days.
intermittant exceptions in TestConcurrentMergeScheduler
---
Key: LUCENE-1018
URL: https
The cause is that in MergeThread.run(), merge in the try block is a
local variable, while merge in the catch block is the class variable.
Merge in the try block could be one different from the original merge,
but the catch block always checks the abort flag of the original
merge.
Ning Li [EMAIL PROTECTED] wrote:
The cause is that in MergeThread.run(), merge in the try block is a
local variable, while merge in the catch block is the class variable.
Merge in the try block could be one different from the original merge,
but the catch block always checks the abort flag of
: But it'd be nice to do this across the board, ie, for any junit test
: if one of CMS's threads (or, threads launched elsewhere) hits an
: unhandled exception, fail the testcase that's currently running.
: I'll dig and see if there's some central way to do this with junit...
FYI: i did some
Michael Busch [EMAIL PROTECTED] wrote:
Hi,
I noticed the following exception in TestConcurrentMergeScheduler:
[junit] Testsuite: org.apache.lucene.index.TestConcurrentMergeScheduler
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 17.765
sec
[junit] -
11 matches
Mail list logo
