Derby
  1. Derby
  2. DERBY-4361

testDefault fixture in engine.ErrorStreamTest has been failing with junit.framework.AssertionFailedError: File C:\jartest\JarResults.XXdateXX\ibm15_suites.All\system\derby.log could not be deleted

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.4.2.1, 10.5.3.1, 10.6.1.0
    • Fix Version/s: 10.4.2.1, 10.5.3.1, 10.6.1.0
    • Component/s: Test
    • Labels:
      None
    • Bug behavior facts:
      Regression Test Failure

      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

      Does anyone know of the cause of the failure?

      1. mamta.java
        7 kB
        Mamta A. Satoor

        Activity

        Hide
        Mamta A. Satoor added a comment -

        Checked in fixes into trunk, 10.5 and 10.4 codeline and didn't see the failure again on my clients so will go ahead and close the jira.

        Show
        Mamta A. Satoor added a comment - Checked in fixes into trunk, 10.5 and 10.4 codeline and didn't see the failure again on my clients so will go ahead and close the jira.
        Hide
        Mamta A. Satoor added a comment -

        backported the changes to 10.4 codeline

        Show
        Mamta A. Satoor added a comment - backported the changes to 10.4 codeline
        Hide
        Mamta A. Satoor added a comment - - edited

        Backported changes into 10.5 codeline using revision 814216

        Show
        Mamta A. Satoor added a comment - - edited Backported changes into 10.5 codeline using revision 814216
        Hide
        Mamta A. Satoor added a comment -

        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);

        Show
        Mamta A. Satoor added a comment - 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);
        Hide
        Mamta A. Satoor added a comment -

        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?

        Show
        Mamta A. Satoor added a comment - 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?
        Hide
        Rick Hillegas added a comment -

        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.

        Show
        Rick Hillegas added a comment - 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.
        Hide
        Mamta A. Satoor added a comment -

        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.

        Show
        Mamta A. Satoor added a comment - 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.
        Hide
        Mamta A. Satoor added a comment -

        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.

        Show
        Mamta A. Satoor added a comment - 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.
        Show
        Ole Solberg added a comment - 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 .
        Hide
        Myrna van Lunteren added a comment -

        I don't know why you don't have access to test results for 15/16/17 August, but perhaps your tests only run when there are changes? There were no check-ins on those days (sort of, depending on your timezone).
        The following check-ins happened on the 17th and 18th:
        r805275 | bpendleton | 2009-08-17 21:38:57 -0700 (Mon, 17 Aug 2009) | 13 lines
        DERBY-4318: Convert inbetween.sql to JUnit
        r805443 | rhillegas | 2009-08-18 08:08:18 -0700 (Tue, 18 Aug 2009) | 1 line
        DERBY-4092: Don't allow invocations of table functions in contexts which expect a scalar function return value.
        r805448 | rhillegas | 2009-08-18 08:25:03 -0700 (Tue, 18 Aug 2009) | 1 line
        DERBY-700: Gracefully handle OverlappingFileLockException if someone attempts to boot a database twice.

        Show
        Myrna van Lunteren added a comment - I don't know why you don't have access to test results for 15/16/17 August, but perhaps your tests only run when there are changes? There were no check-ins on those days (sort of, depending on your timezone). The following check-ins happened on the 17th and 18th: r805275 | bpendleton | 2009-08-17 21:38:57 -0700 (Mon, 17 Aug 2009) | 13 lines DERBY-4318 : Convert inbetween.sql to JUnit r805443 | rhillegas | 2009-08-18 08:08:18 -0700 (Tue, 18 Aug 2009) | 1 line DERBY-4092 : Don't allow invocations of table functions in contexts which expect a scalar function return value. r805448 | rhillegas | 2009-08-18 08:25:03 -0700 (Tue, 18 Aug 2009) | 1 line DERBY-700 : Gracefully handle OverlappingFileLockException if someone attempts to boot a database twice.

          People

          • Assignee:
            Mamta A. Satoor
            Reporter:
            Mamta A. Satoor
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development