Derby
  1. Derby
  2. DERBY-5040

On Windows, cascade of errors after failed test AutomaticIndexStatisticsTest

    Details

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

      Description

      Cf log here:

      http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-1070264.html

      Not sure if this is distinct (or not) from other errors we have seen after the enabling of the statistics auto-refresh patch.

        Issue Links

          Activity

          Hide
          Kristian Waagan added a comment -

          I see that the first test that failed was AutomaticIndexStatisticsTest.testStatsCreatedOnGrowthThenDeleteDb. The problem was that one of the data files in the seg0 directory could not be deleted. Since all the other files got deleted, this is now basically a very corrupt database... Derby is not, or rather has not been made, capable of deleting an existing directory structure in the default case, and thus all tests accessing the default database wombat fails.

          Again this intermittent delete issue causes trouble, and I believe it happens only on Windows. I've seen something similar with the upgrade test on my machine (Windows Vista).
          I'm not sure if the istat daemon can cause Derby to keep file handles open after shutdown, but maybe it can if the timing is right (i.e. calling a path that involves reopening a container if it has already been closed).

          I see at least two ways to progress on this problem:
          a) Make the delete method more persistent by adding a sleep after the first iteration of deletes, and then try to delete all remaining files in a second pass. Could also repeat if required. If the files cannot be deleted after X iterations, there must be a real resource handling bug.
          b) If easily reproducible, debug to find out if there are open file handles and if so figure out why. I don't know if you can easily map a file handle to something inside the Java process though, so this may involve a fair amount of code inspection and debugging.

          Show
          Kristian Waagan added a comment - I see that the first test that failed was AutomaticIndexStatisticsTest.testStatsCreatedOnGrowthThenDeleteDb. The problem was that one of the data files in the seg0 directory could not be deleted. Since all the other files got deleted, this is now basically a very corrupt database... Derby is not, or rather has not been made, capable of deleting an existing directory structure in the default case, and thus all tests accessing the default database wombat fails. Again this intermittent delete issue causes trouble, and I believe it happens only on Windows. I've seen something similar with the upgrade test on my machine (Windows Vista). I'm not sure if the istat daemon can cause Derby to keep file handles open after shutdown, but maybe it can if the timing is right (i.e. calling a path that involves reopening a container if it has already been closed). I see at least two ways to progress on this problem: a) Make the delete method more persistent by adding a sleep after the first iteration of deletes, and then try to delete all remaining files in a second pass. Could also repeat if required. If the files cannot be deleted after X iterations, there must be a real resource handling bug. b) If easily reproducible, debug to find out if there are open file handles and if so figure out why. I don't know if you can easily map a file handle to something inside the Java process though, so this may involve a fair amount of code inspection and debugging.
          Hide
          Kristian Waagan added a comment -

          Attaching patch 1a, which makes the failing test use a separate database instead of the default database wombat.
          This should eliminate the cascade of errors.

          Note that this patch doesn't address the underlying cause for not being able to delete the database directory.

          Show
          Kristian Waagan added a comment - Attaching patch 1a, which makes the failing test use a separate database instead of the default database wombat. This should eliminate the cascade of errors. Note that this patch doesn't address the underlying cause for not being able to delete the database directory.
          Hide
          Kristian Waagan added a comment -

          Committed to trunk with revision 1071783.

          Show
          Kristian Waagan added a comment - Committed to trunk with revision 1071783.
          Hide
          Rick Hillegas added a comment -

          This issue may be a duplicate of DERBY-5026.

          Show
          Rick Hillegas added a comment - This issue may be a duplicate of DERBY-5026 .
          Hide
          Kristian Waagan added a comment -

          The cascade-effect has been fixed by switching from using the default db to a separate db.
          The test failure itself is hopefully adressed by DERBY-4915.

          I don't expect more work for this issue.

          Show
          Kristian Waagan added a comment - The cascade-effect has been fixed by switching from using the default db to a separate db. The test failure itself is hopefully adressed by DERBY-4915 . I don't expect more work for this issue.
          Hide
          Knut Anders Hatlen added a comment -

          [bulk update: close all resolved issues that haven't had any activity the last year]

          Show
          Knut Anders Hatlen added a comment - [bulk update: close all resolved issues that haven't had any activity the last year]

            People

            • Assignee:
              Kristian Waagan
              Reporter:
              Dag H. Wanvik
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development