Uploaded image for project: '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
          kristwaa 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
          kristwaa 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
          kristwaa 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
          kristwaa 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
          kristwaa Kristian Waagan added a comment -

          Committed to trunk with revision 1071783.

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

          This issue may be a duplicate of DERBY-5026.

          Show
          rhillegas Rick Hillegas added a comment - This issue may be a duplicate of DERBY-5026 .
          Hide
          kristwaa 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
          kristwaa 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
          knutanders Knut Anders Hatlen added a comment -

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

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

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development