Derby
  1. Derby
  2. DERBY-4915

test failure in OSReadOnlyTest in assertDirectoryDeleted

    Details

    • Urgency:
      Normal
    • Bug behavior facts:
      Regression Test Failure

      Description

      I've seen the assert flag a failure for deleteing a log file last night, and a seg0 file the night before.

      This is one stack trace:

      1) testOSReadOnly(org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest)junit.framework.AssertionFailedError: Failed to delete 2 files (root=F:\test\JarResults.2010-11-23\ibm16_suites.All\system\singleUse\readWrite: F:\test\JarResults.2010-11-23\ibm16_suites.All\system\singleUse\readWrite\log (isDir=true, canRead=true, canWrite=true, size=0), F:\jartest\JarResults.2010-11-23\ibm16_suites.All\system\singleUse\readWrite (isDir=true, canRead=true, canWrite=true, size=0)
      at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertDirectoryDeleted(BaseJDBCTestCase.java:1421)
      at org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest.moveDatabaseOnOS(OSReadOnlyTest.java:295)
      at org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest.testOSReadOnly(OSReadOnlyTest.java:160)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
      at junit.extensions.TestSetup.run(TestSetup.java:16)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
      at junit.extensions.TestSetup.run(TestSetup.java:16)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
      at junit.extensions.TestSetup.run(TestSetup.java:16)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
      at junit.extensions.TestSetup.run(TestSetup.java:16)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
      at junit.extensions.TestSetup.run(TestSetup.java:16)

      This is another:
      1) testOSReadOnly(org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest)junit.framework.AssertionFailedError: Failed to delete 2 files (root=F:\test\JarResults.2010-11-22\ibm16_suites.All\system\singleUse\readOnly: F:\test\JarResults.2010-11-22\ibm16_suites.All\system\singleUse\readOnly\seg0 (isDir=true, canRead=true, canWrite=true, size=0), F:\jartest\JarResults.2010-11-22\ibm16_suites.All\system\singleUse\readOnly (isDir=true, canRead=true, canWrite=true, size=0)
      at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertDirectoryDeleted(BaseJDBCTestCase.java:1421)
      at org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest.moveDatabaseOnOS(OSReadOnlyTest.java:295)
      at org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest.testOSReadOnly(OSReadOnlyTest.java:152)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
      at junit.extensions.TestSetup.run(TestSetup.java:16)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
      at junit.extensions.TestSetup.run(TestSetup.java:16)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
      at junit.extensions.TestSetup.run(TestSetup.java:16)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
      at junit.extensions.TestSetup.run(TestSetup.java:16)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
      at junit.extensions.TestSetup.run(TestSetup.java:16)

      This is on a machine that I've been able to arrange for a windows machine on which to run the tests for 10.7 nightly, but this is not a new machine. So perhaps the disk - being older - is a little slow in deleting? Perhaps the check can be delayed, or redone if failed first time.

      I'm still investigating, checking on hardware settings. The disk scan showed up healthy, and multithreading is not on.

      1. derby-4915-1a-more_persistent_delete.diff
        3 kB
        Kristian Waagan
      2. derby-4915-1b-more_persistent_delete.diff
        4 kB
        Kristian Waagan
      3. derby-4915-2a-increased_sleep.diff
        2 kB
        Kristian Waagan

        Issue Links

          Activity

          Hide
          Kristian Waagan added a comment -

          Hi Myrna,

          The delete method returns a list of files it couldn't delete. Should be easy to try to delete them again (maybe even multiple times or with added sleep time etc).
          Would be good to know if this happens with JDKs from other vendors as well. I'm debugging a similar issue, but in another test (see DERBY-4916). Here the delete problem happens in another delete method and another JDK.

          Show
          Kristian Waagan added a comment - Hi Myrna, The delete method returns a list of files it couldn't delete. Should be easy to try to delete them again (maybe even multiple times or with added sleep time etc). Would be good to know if this happens with JDKs from other vendors as well. I'm debugging a similar issue, but in another test (see DERBY-4916 ). Here the delete problem happens in another delete method and another JDK.
          Hide
          Myrna van Lunteren added a comment -

          I saw this also in a nightly run with 10.7.1.2 - synced to revision 1040394, with ibm 1.5 (sr11); failing to delete the dir <startingdir>system\singleUse\readOnly:

          at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertDirectoryDeleted(BaseJDBCTestCase.java:1421)
          at org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest.moveDatabaseOnOS(OSReadOnlyTest.java:295)
          at org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest.testOSReadOnly(OSReadOnlyTest.java:152)
          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)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)
          at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)
          at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)

          Show
          Myrna van Lunteren added a comment - I saw this also in a nightly run with 10.7.1.2 - synced to revision 1040394, with ibm 1.5 (sr11); failing to delete the dir <startingdir>system\singleUse\readOnly: at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertDirectoryDeleted(BaseJDBCTestCase.java:1421) at org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest.moveDatabaseOnOS(OSReadOnlyTest.java:295) at org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest.testOSReadOnly(OSReadOnlyTest.java:152) 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) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23)
          Hide
          Rick Hillegas added a comment -

          I looked through the bug fixes which made it into the 10.7 branch but not into 10.6.2. Only one fix seemed relevant, based on it description: DERBY-4804. May be a red herring, but it might be worthwhile to try backing out that fix and see if the problem goes away.

          Show
          Rick Hillegas added a comment - I looked through the bug fixes which made it into the 10.7 branch but not into 10.6.2. Only one fix seemed relevant, based on it description: DERBY-4804 . May be a red herring, but it might be worthwhile to try backing out that fix and see if the problem goes away.
          Hide
          Mike Matrigali added a comment -

          Continues to be an intermittent problem. Here is a example in the ibm15 run on 2/15/2011 against build 1071131 of the 10.7 branch

          http://people.apache.org/~myrnavl/derby_test_results/v10_7/windows/testlog/ibm15/1071131-suites.All_diff.txt

          There was 1 failure:
          1) testOSReadOnly(org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest)junit.framework.AssertionFailedError: Failed to delete 1 files (root=F:\jartest\JarResults.2011-02-15\ibm15_suites.All\system\singleUse\readOnly: F:\jartest\JarResults.2011-02-15\ibm15_suites.All\system\singleUse\readOnly (isDir=true, canRead=true, canWrite=true, size=0)
          at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertDirectoryDeleted(BaseJDBCTestCase.java:1421)
          at org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest.moveDatabaseOnOS(OSReadOnlyTest.java:295)
          at org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest.testOSReadOnly(OSReadOnlyTest.java:152)
          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)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)
          at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)
          at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)

          Show
          Mike Matrigali added a comment - Continues to be an intermittent problem. Here is a example in the ibm15 run on 2/15/2011 against build 1071131 of the 10.7 branch http://people.apache.org/~myrnavl/derby_test_results/v10_7/windows/testlog/ibm15/1071131-suites.All_diff.txt There was 1 failure: 1) testOSReadOnly(org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest)junit.framework.AssertionFailedError: Failed to delete 1 files (root=F:\jartest\JarResults.2011-02-15\ibm15_suites.All\system\singleUse\readOnly: F:\jartest\JarResults.2011-02-15\ibm15_suites.All\system\singleUse\readOnly (isDir=true, canRead=true, canWrite=true, size=0) at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertDirectoryDeleted(BaseJDBCTestCase.java:1421) at org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest.moveDatabaseOnOS(OSReadOnlyTest.java:295) at org.apache.derbyTesting.functionTests.tests.store.OSReadOnlyTest.testOSReadOnly(OSReadOnlyTest.java:152) 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) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23)
          Hide
          Kristian Waagan added a comment -

          Attaching patch 1a, which makes the delete method more persistent. It will now try to delete any files three times before giving up.

          Using this patch, I was unable to reproduce the delete failure in osReadOnlyTest, but I did see the debug print telling that the first attempt left one file behind.
          It is not clear to me if this is a problem caused by slowness in Derby, the test framwork, or the file/operating system. On my system the failure or printout could be observed from zero to two times per 50 runs.

          Before committing this patch, I'd like to hear if people think it is acceptable to mask potential problems in this area by retrying the delete operation.

          Note that the patch won't fix all occurrences of this issue, since most tests/decorators use another delete method.

          Patch ready for review.

          Show
          Kristian Waagan added a comment - Attaching patch 1a, which makes the delete method more persistent. It will now try to delete any files three times before giving up. Using this patch, I was unable to reproduce the delete failure in osReadOnlyTest, but I did see the debug print telling that the first attempt left one file behind. It is not clear to me if this is a problem caused by slowness in Derby, the test framwork, or the file/operating system. On my system the failure or printout could be observed from zero to two times per 50 runs. Before committing this patch, I'd like to hear if people think it is acceptable to mask potential problems in this area by retrying the delete operation. Note that the patch won't fix all occurrences of this issue, since most tests/decorators use another delete method. Patch ready for review.
          Hide
          Mike Matrigali added a comment -

          The OSReadOnly test is a single use database test, which explains why it is having trouble with cleanup more often than other
          tests. It also does some file manupulation of the database files itself.

          I think the patch looks good and would be fine with it being checked in. I agree with the comments that a real derby bug would more
          likely just keep the file open forevery than just a little while after closing. A reasonable derby explanation of current behavior would be that a "shutdown=true" actually does not wait for a complete shutdown before returning - so a shutdown could be happening while the cleanup is happening. Or it could be a delayed write thing on windows. I am not sure why this is happening recently and not in older
          code lines - but maybe the tests have changed.

          It might be reasonable to put in a slight wait in harness after any attempt to shutdown a database, as I think this is what we tell customers.

          Show
          Mike Matrigali added a comment - The OSReadOnly test is a single use database test, which explains why it is having trouble with cleanup more often than other tests. It also does some file manupulation of the database files itself. I think the patch looks good and would be fine with it being checked in. I agree with the comments that a real derby bug would more likely just keep the file open forevery than just a little while after closing. A reasonable derby explanation of current behavior would be that a "shutdown=true" actually does not wait for a complete shutdown before returning - so a shutdown could be happening while the cleanup is happening. Or it could be a delayed write thing on windows. I am not sure why this is happening recently and not in older code lines - but maybe the tests have changed. It might be reasonable to put in a slight wait in harness after any attempt to shutdown a database, as I think this is what we tell customers.
          Hide
          Kathey Marsden added a comment -

          Would it cause problems with the nightly output parsing if we always printed out a list of the remaining files when we have to retry. It would be interesting over time to see if it is always the same ones and since we don't really understand the root cause it might help in future diagnostics.

          I seem to recall user cases where we had to tell them to sleep before rapidly rebooting a database after shutdown. It would be nice to have something to call to see if the shutdown is really complete or better prevent shutdown from returning until we are really shutdown.

          Show
          Kathey Marsden added a comment - Would it cause problems with the nightly output parsing if we always printed out a list of the remaining files when we have to retry. It would be interesting over time to see if it is always the same ones and since we don't really understand the root cause it might help in future diagnostics. I seem to recall user cases where we had to tell them to sleep before rapidly rebooting a database after shutdown. It would be nice to have something to call to see if the shutdown is really complete or better prevent shutdown from returning until we are really shutdown.
          Hide
          Kristian Waagan added a comment -

          Attached patch 1b, which makes the method print the names of the files it could not delete to standard out and makes DropDatabaseSetup.removeDir use assertDirectoryDeleted.

          Committed to trunk with revision 1076335.

          Do we need to log an issue to remember that certain types of "slowness" (see comment above) are now masked by the test framework, or is that insignificant?

          For the record, on my machine I saw that the test had problems deleting the directories 'readOnly', 'readOnly2', 'oneuse0', 'oneuse1', and 'readWrite'. All the files within the directories seemed to be deleted.
          I ran maybe around 700 iterations of the test (Windows Vista, Cygwin, Java 6).

          Show
          Kristian Waagan added a comment - Attached patch 1b, which makes the method print the names of the files it could not delete to standard out and makes DropDatabaseSetup.removeDir use assertDirectoryDeleted. Committed to trunk with revision 1076335. Do we need to log an issue to remember that certain types of "slowness" (see comment above) are now masked by the test framework, or is that insignificant? For the record, on my machine I saw that the test had problems deleting the directories 'readOnly', 'readOnly2', 'oneuse0', 'oneuse1', and 'readWrite'. All the files within the directories seemed to be deleted. I ran maybe around 700 iterations of the test (Windows Vista, Cygwin, Java 6).
          Hide
          Kristian Waagan added a comment -

          Resolving for now to make sure it makes it into the release notes.
          Please reopen if it turns out the fix is inadequate.

          Show
          Kristian Waagan added a comment - Resolving for now to make sure it makes it into the release notes. Please reopen if it turns out the fix is inadequate.
          Hide
          Myrna van Lunteren added a comment -

          Thanks Kristian!
          We'll assume it's fixed - unless it shows up again, I don't intend to run the test x00 times now.

          I hadn't seen the failure for a while on trunk, but coincidentally it happened on 10.7 just a day before you checked in:
          10.7.1.3 - (1076096) (see: http://people.apache.org/~myrnavl/derby_test_results/v10_7/windows/testSummary-1076096.html). At least - looks like the same issue to me.
          Did you plan to backport this to 10.7?

          Show
          Myrna van Lunteren added a comment - Thanks Kristian! We'll assume it's fixed - unless it shows up again, I don't intend to run the test x00 times now. I hadn't seen the failure for a while on trunk, but coincidentally it happened on 10.7 just a day before you checked in: 10.7.1.3 - (1076096) (see: http://people.apache.org/~myrnavl/derby_test_results/v10_7/windows/testSummary-1076096.html ). At least - looks like the same issue to me. Did you plan to backport this to 10.7?
          Hide
          Kristian Waagan added a comment -

          I'll see if it can be easily backported once we're a bit more confident that it fixes the problem - maybe after the RC has been tested?

          Show
          Kristian Waagan added a comment - I'll see if it can be easily backported once we're a bit more confident that it fixes the problem - maybe after the RC has been tested?
          Hide
          Myrna van Lunteren added a comment -

          OK...Thx...

          Show
          Myrna van Lunteren added a comment - OK...Thx...
          Hide
          Kristian Waagan added a comment -

          Reopening, the bug is still seen.

          Show
          Kristian Waagan added a comment - Reopening, the bug is still seen.
          Hide
          Kristian Waagan added a comment -

          I was unable to attach the patch (permission issue in JIRA according to the error message), but I committed it to trunk with revision 1078608 nonetheless.
          I will upload the patch later.

          The patch makes the sleep time longer, and it also makes the method try to delete remaining files one additional time. If the failures persists, there is likely that a Derby bug is keeping a handle open (timing dependent?).

          Show
          Kristian Waagan added a comment - I was unable to attach the patch (permission issue in JIRA according to the error message), but I committed it to trunk with revision 1078608 nonetheless. I will upload the patch later. The patch makes the sleep time longer, and it also makes the method try to delete remaining files one additional time. If the failures persists, there is likely that a Derby bug is keeping a handle open (timing dependent?).
          Hide
          Kristian Waagan added a comment -

          Attached patch 2a (already committed).

          Show
          Kristian Waagan added a comment - Attached patch 2a (already committed).
          Hide
          Kristian Waagan added a comment -

          Resolving again.
          I haven't seen the failure in OSReadOnlyTest since the fix went in, but I have observed a similar failure in at least one of the AutomaticIndexStatisticsTest. This issue will be tracked as as DERBY-5108.

          Please reopen if you spot the failure in OSReadOnlyTest.

          Show
          Kristian Waagan added a comment - Resolving again. I haven't seen the failure in OSReadOnlyTest since the fix went in, but I have observed a similar failure in at least one of the AutomaticIndexStatisticsTest. This issue will be tracked as as DERBY-5108 . Please reopen if you spot the failure in OSReadOnlyTest.
          Hide
          Mamta A. Satoor added a comment -

          I saw the failure on 10.7.1.4 codeline with ibm15. Is that because this jira has not been backported to 10.7?

          Show
          Mamta A. Satoor added a comment - I saw the failure on 10.7.1.4 codeline with ibm15. Is that because this jira has not been backported to 10.7?
          Hide
          Kristian Waagan added a comment -

          Yes, that's likely. The issue is only seen on some JVMs/machines.
          Backported to 10.7 with revision 1154956.

          Show
          Kristian Waagan added a comment - Yes, that's likely. The issue is only seen on some JVMs/machines. Backported to 10.7 with revision 1154956.
          Hide
          Kristian Waagan added a comment -

          Marking this as inappropriate for backporting further than 10.7.
          It could be backported if someone really wants it, but in my opinion it's not worth it. You would have to resolve two conflicts and backport at least one additional fix. After that the new delete code would be used by DropDatabaseSetup, but no tests would use the new code directly.

          Show
          Kristian Waagan added a comment - Marking this as inappropriate for backporting further than 10.7. It could be backported if someone really wants it, but in my opinion it's not worth it. You would have to resolve two conflicts and backport at least one additional fix. After that the new delete code would be used by DropDatabaseSetup, but no tests would use the new code directly.
          Hide
          Knut Anders Hatlen added a comment -

          [bulk update] Close all resolved issues that haven't been updated for more than one year.

          Show
          Knut Anders Hatlen added a comment - [bulk update] Close all resolved issues that haven't been updated for more than one year.

            People

            • Assignee:
              Kristian Waagan
              Reporter:
              Myrna van Lunteren
            • Votes:
              1 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development