[
https://issues.apache.org/jira/browse/LUCENE-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-1018.
Resolution: Fixed
I just committed this.
> intermittant exceptions
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
>
intermittant exceptions in TestConcurrentMergeScheduler
---
Key: LUCENE-1018
URL: https://issues.apache.org/jira/browse/LUCENE-1018
Project: Lucene - Java
Issue Type: Bug
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 ca
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 implement
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. So
"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 ce
: 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 casu
"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
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.
-
> I can't get this to happen. Which OS/hardware are you seeing this on?
>
I seeing it on my Laptop: 2.0 GHz Centrino, 2 GB RAM, Windows XP, Sun
JRE 1.5.0_06.
I tried the testcase a couple more times and it's approximately failing
in 1 to 2 runs out of 10.
> But it'd be nice to do this across t
"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] ---
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] - Standard Error -
[junit] Excepti
13 matches
Mail list logo
