Description

testDefault fixture has been failing atleast since August 18th 2009 with following exception. I do not have access to test results fro 15th, 16th and 17th so not sure if the failure started earlier. It seemed to have run find on August 14th 2009.
1) testDefault(org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest)junit.framework.AssertionFailedError: File C:\jartest\JarResults.2009-08-18\ibm15_suites.All\system\derby.log could not be deleted
at org.apache.derbyTesting.functionTests.tests.engine.ErrorStreamTest.testDefault(ErrorStreamTest.java:135)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109)

This is happening both on trunk and 10.5 codelines. Not sure of other codelines. The failure appears on Windows but not on Linux. The jvms that definitely show the failures are ibm 15 and ibm16

Ole Solberg
added a comment - 27/Aug/09 08:36 Also seen in the Sun testing: http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/Limited/ , http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.5/testing/Limited/ and http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.4/testing/Limited/ .
I see that this is the same failure signature and method as in DERBY-3202 . See e.g. http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/FailReports/808072_bySig.html .

I modified AllPackages.java to run only following to see if I can reproduce the problem but that didn't help either.
suite.addTest(org.apache.derbyTesting.functionTests.tests.tools._Suite.suite());
suite.addTest(org.apache.derbyTesting.functionTests.tests.engine._Suite.suite());

I will try to add few more suites to see what consistently reproduces the problem and debug it further.

I looked at DERBY-3202 and it appears that this exact failure was noticed there and apparently after the fix went in for DERBY-3202, it was not reported again so I am not sure what has triggered it back.

Mamta A. Satoor
added a comment - 31/Aug/09 20:16 I ran the test standalone and that doesn't repro the failure.
Running it's suite also didn't repro the problem (it belongs to engine._suite).
I modified AllPackages.java to run only following to see if I can reproduce the problem but that didn't help either.
suite.addTest(org.apache.derbyTesting.functionTests.tests.tools._Suite.suite());
suite.addTest(org.apache.derbyTesting.functionTests.tests.engine._Suite.suite());
I will try to add few more suites to see what consistently reproduces the problem and debug it further.
I looked at DERBY-3202 and it appears that this exact failure was noticed there and apparently after the fix went in for DERBY-3202 , it was not reported again so I am not sure what has triggered it back.

It appears that the problem can be consistently produced with having just two suites and I have changed store suite to only run suite.addTest(ClassLoaderBootTest.suite());
suite.addTest(org.apache.derbyTesting.functionTests.tests.store._Suite.suite());
suite.addTest(org.apache.derbyTesting.functionTests.tests.engine._Suite.suite());

If I switch the order of the 2 suites above, the problem does not occur. So, it appears that the problem may have been caused by DERBY-700 which introduced the test ClassLoaderBootTest. I will look futher into DERBY-700 changes but will appreciate if someone has insight on what is the dependency between ClassLoaderBootTest and ErrorStreamTest.

Mamta A. Satoor
added a comment - 02/Sep/09 13:35 It appears that the problem can be consistently produced with having just two suites and I have changed store suite to only run suite.addTest(ClassLoaderBootTest.suite());
suite.addTest(org.apache.derbyTesting.functionTests.tests.store._Suite.suite());
suite.addTest(org.apache.derbyTesting.functionTests.tests.engine._Suite.suite());
If I switch the order of the 2 suites above, the problem does not occur. So, it appears that the problem may have been caused by DERBY-700 which introduced the test ClassLoaderBootTest. I will look futher into DERBY-700 changes but will appreciate if someone has insight on what is the dependency between ClassLoaderBootTest and ErrorStreamTest.

I notice that this test fails under Java 5. On that VM, only one of the ClassLoaderBootTests runs. That is testBootingDatabaseShutdownByAnotherCLR(). That test does the following:

1) Boots a database in a separate class loader

2) Shuts down the database

3) Boots the database in a second class loader

4) Shuts down the database

Maybe ClassLoaderBootTest needs to shutdown the engine and not just shutdown the database. I can't test this theory because the tests run cleanly on my Mac OS X platform. But maybe you could try out this experiment on windows.

Rick Hillegas
added a comment - 02/Sep/09 19:45 Hi Mamta,
I notice that this test fails under Java 5. On that VM, only one of the ClassLoaderBootTests runs. That is testBootingDatabaseShutdownByAnotherCLR(). That test does the following:
1) Boots a database in a separate class loader
2) Shuts down the database
3) Boots the database in a second class loader
4) Shuts down the database
Maybe ClassLoaderBootTest needs to shutdown the engine and not just shutdown the database. I can't test this theory because the tests run cleanly on my Mac OS X platform. But maybe you could try out this experiment on windows.

Thanks for your comment, Rick. I tried putting at the end of testBootingDatabaseShutdownByAnotherCLR()
getTestConfiguration().shutdownEngine();
Shutting down the engine this way didn't fix the problem. Is that the right way of shutting down the engine when dealing with classloader scenario?

Mamta A. Satoor
added a comment - 03/Sep/09 00:06 Thanks for your comment, Rick. I tried putting at the end of testBootingDatabaseShutdownByAnotherCLR()
getTestConfiguration().shutdownEngine();
Shutting down the engine this way didn't fix the problem. Is that the right way of shutting down the engine when dealing with classloader scenario?

Checked in a fix for the problem earlier today with revision 812669. As Rick correctly pointed out, it was not enough to just shutdown the database on Windows machine. I added the code to shutdown the engine using the supplied datasource as the parameter. It is not enough to use the existing method getTestConfiguration().shutdownEngine();
to shutdown the engine because we want to shutdown the Derby instance created by the different classloaders here.

I am attaching a very crude standalone version of the bug behavior (mamta.java). The bug behavior can be seen if one were to comment out the calls to datasource shutdown engine code in mamta.java
JDBCDataSource.shutEngine(ds_2);
JDBCDataSource.shutEngine(ds_1);

Mamta A. Satoor
added a comment - 09/Sep/09 01:22 Checked in a fix for the problem earlier today with revision 812669. As Rick correctly pointed out, it was not enough to just shutdown the database on Windows machine. I added the code to shutdown the engine using the supplied datasource as the parameter. It is not enough to use the existing method getTestConfiguration().shutdownEngine();
to shutdown the engine because we want to shutdown the Derby instance created by the different classloaders here.
I am attaching a very crude standalone version of the bug behavior (mamta.java). The bug behavior can be seen if one were to comment out the calls to datasource shutdown engine code in mamta.java
JDBCDataSource.shutEngine(ds_2);
JDBCDataSource.shutEngine(ds_1);