Derby
  1. Derby
  2. DERBY-4833

Prepare existing JUnit tests for running with automatic index statistics generation

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.7.1.1
    • Fix Version/s: 10.8.1.2
    • Component/s: Test
    • Labels:
      None

      Description

      During prototyping of a mechanism to create and update index statistics automatically (see DERBY-4771) it turned out that some of the tests fail due to the presence of [improved] index statistics.
      Where appropriate the tests should be adjusted to cope with this background activity, and where not appropriate it should be noted such that the feature, when introduced, can be disabled.

      As part of this effort I will introduce a utility class for dealing with index statistics in tests. These will be used by some existing tests and also the new tests that will be written for the new feature.

      At this point two tests requiring adjustments have been identified (OrderByAndSortAvoidance, UpdateStatisticsTest), and one is under investigation (AutoIncrementTest). More may surface as the work on the feature progress.

        Issue Links

          Activity

          Hide
          Kristian Waagan added a comment -

          Added link to DERBY-4804, since the problem was detected due to the automatic index statistics update prototype.

          Show
          Kristian Waagan added a comment - Added link to DERBY-4804 , since the problem was detected due to the automatic index statistics update prototype.
          Hide
          Kristian Waagan added a comment -

          Attaching patch 1a, which removes two (identical) asserts in the lang.OrderByAndSortAvoidance test.
          Depending on whether index statistics are present or not, Derby will choose a table scan or an index scan. This choice is not crucial to the issue being tested, so it should be safe to remove the assert.

          Patch ready for review.

          Show
          Kristian Waagan added a comment - Attaching patch 1a, which removes two (identical) asserts in the lang.OrderByAndSortAvoidance test. Depending on whether index statistics are present or not, Derby will choose a table scan or an index scan. This choice is not crucial to the issue being tested, so it should be safe to remove the assert. Patch ready for review.
          Hide
          Kristian Waagan added a comment -

          Committed patch 1a to trunk with revision 1005804.

          Show
          Kristian Waagan added a comment - Committed patch 1a to trunk with revision 1005804.
          Hide
          Kristian Waagan added a comment -

          Attaching patch 2a, which disabled automatic index stats update for the test store/updatelocks.sql.
          The locks taken, or possibly timing differences, are interfering with the test.There are also reports of intermittent failures for this test (before any of the new istat code was added).

          Patch ready for review.

          Show
          Kristian Waagan added a comment - Attaching patch 2a, which disabled automatic index stats update for the test store/updatelocks.sql. The locks taken, or possibly timing differences, are interfering with the test.There are also reports of intermittent failures for this test (before any of the new istat code was added). Patch ready for review.
          Hide
          Knut Anders Hatlen added a comment -

          Patch 2a looks fine to me. This is a problem that can happen in any test that checks the contents of the lock table, isn't it? Do you think we'll need some systematic approach to handle this problem, or would it be good enough to handle each occurrence on a case-by-case basis as they show up? (With systematic approach I was thinking something like disabling automatic index statistics update in every test that queries SYSCS_DIAG.LOCK_TABLE, or adding a procedure that waits until the update thread's queue is empty, similar to T_Access.waitForPostCommitToFinish().)

          Show
          Knut Anders Hatlen added a comment - Patch 2a looks fine to me. This is a problem that can happen in any test that checks the contents of the lock table, isn't it? Do you think we'll need some systematic approach to handle this problem, or would it be good enough to handle each occurrence on a case-by-case basis as they show up? (With systematic approach I was thinking something like disabling automatic index statistics update in every test that queries SYSCS_DIAG.LOCK_TABLE, or adding a procedure that waits until the update thread's queue is empty, similar to T_Access.waitForPostCommitToFinish().)
          Hide
          Kristian Waagan added a comment -

          Yes, this can happen in all tests that query the lock table, but there are various prerequisites that must be met before the automatic index statistics updates kick in (these may change with the implementation/tuning).
          A quick find/grep resulted in something like 22 hits (on the file level) in the tests directory, and 24 in the masters directory.

          I have run both suites.All and derbyall numerours times without having seen other problems, but that may change on other machines and operating systems.
          If we address this up-front, I would lean towards adding a way to wait for the updates to finish to potentially get more test coverage for the feature, but disabling it would also work fine.

          I don't have any strong feelings about this right now, and more importantly, I don't have much time to work on it now...
          If people start seeing intermittent failures when the feature has been committed, it would probably be best to address all affected tests in one go.

          Show
          Kristian Waagan added a comment - Yes, this can happen in all tests that query the lock table, but there are various prerequisites that must be met before the automatic index statistics updates kick in (these may change with the implementation/tuning). A quick find/grep resulted in something like 22 hits (on the file level) in the tests directory, and 24 in the masters directory. I have run both suites.All and derbyall numerours times without having seen other problems, but that may change on other machines and operating systems. If we address this up-front, I would lean towards adding a way to wait for the updates to finish to potentially get more test coverage for the feature, but disabling it would also work fine. I don't have any strong feelings about this right now, and more importantly, I don't have much time to work on it now... If people start seeing intermittent failures when the feature has been committed, it would probably be best to address all affected tests in one go.
          Hide
          Knut Anders Hatlen added a comment -

          It sounds reasonable to wait and see if intermittent failures start appearing in those test, and addressing all in one go if they do. Since the statistics updates don't kick in unless the tables are above a certain minimum size, it might not be a problem in most of those tests anyway.

          Show
          Knut Anders Hatlen added a comment - It sounds reasonable to wait and see if intermittent failures start appearing in those test, and addressing all in one go if they do. Since the statistics updates don't kick in unless the tables are above a certain minimum size, it might not be a problem in most of those tests anyway.
          Hide
          Kristian Waagan added a comment -

          The initial istat related problems seen with the updatelocksX were solved by changing the threshold values (i.e. upping the minimum number of rows required before the istat daemon considers an update). This means patch 2a probably doesn't need to be committed.
          In any case, there are still problems with the updatelocksX tests, but it is my impression that they're not caused by the istat feature. Keeping this issue open a little while longer, hoping we figure out what the underlying problem is.

          Show
          Kristian Waagan added a comment - The initial istat related problems seen with the updatelocksX were solved by changing the threshold values (i.e. upping the minimum number of rows required before the istat daemon considers an update). This means patch 2a probably doesn't need to be committed. In any case, there are still problems with the updatelocksX tests, but it is my impression that they're not caused by the istat feature. Keeping this issue open a little while longer, hoping we figure out what the underlying problem is.
          Hide
          Kristian Waagan added a comment -

          Closing issue.
          The failing updateLocks tests have now been rewritten to JUnit, see DERBY-5305.

          Show
          Kristian Waagan added a comment - Closing issue. The failing updateLocks tests have now been rewritten to JUnit, see DERBY-5305 .
          Hide
          Dag H. Wanvik added a comment -

          Not sure which one failed here, but the updateLocksJDBC30.sql is not converted yet.

          Show
          Dag H. Wanvik added a comment - Not sure which one failed here, but the updateLocksJDBC30.sql is not converted yet.

            People

            • Assignee:
              Kristian Waagan
              Reporter:
              Kristian Waagan
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development