Derby
  1. Derby
  2. DERBY-5440

test failure in testBTreeForwardScan_fetchRows_resumeAfterWait_nonUnique_split(org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest)junit.framework.AssertionFailedError: expected:<1> but was:<0>

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: 10.8.2.2
    • Fix Version/s: 10.8.3.0, 10.9.1.0
    • Component/s: Test
    • Labels:
      None
    • Environment:
      IBM iseries 6.1, Classic 1.6 JVM
    • Bug behavior facts:
      Regression Test Failure

      Description

      During the QA Cycle for 10.8.2.1 I also ran on a next version of the iseries OS, and saw this failure. It did not reproduce when I reran the test by itself. The test has the following comment:
      // Give the other thread time to obtain the lock
      Thread.sleep(1000);

      // Perform an index scan. Will be blocked for a while when fetching
      // the row where x=100, but should be able to resume the scan.
      ResultSet rs = s.executeQuery(
      "select * from t --DERBY-PROPERTIES index=IDX");
      for (int i = 0; i < 300; i++)

      { assertTrue(rs.next()); assertEquals(i, rs.getInt(1)); <==== this is the line of the failure. }

      I think this is a rather slow machine, and that's likely why I saw the failure, perhaps the sleep wasn't long enough on this machine.
      Here is the stack trace:

      1) testBTreeForwardScan_fetchRows_resumeAfterWait_nonUnique_split(org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest)junit.framework.AssertionFailedError: expected:<1> but was:<0>
      at java.lang.Throwable.<init>(Throwable.java:195)
      at java.lang.Error.<init>(Error.java:49)
      at junit.framework.AssertionFailedError.<init>(AssertionFailedError.java:13)
      at org.apache.derbyTesting.functionTests.tests.store.IndexSplitDeadlockTest.testBTreeForwardScan_fetchRows_resumeAfterWait_nonUnique_split(IndexSplitDeadlockTest.java:526)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:27)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:92)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
      at junit.extensions.TestSetup.run(TestSetup.java:25)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
      at junit.extensions.TestSetup.run(TestSetup.java:25)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

      derby.log has no useful info.

      1. d5440-2.diff
        8 kB
        Knut Anders Hatlen
      2. d5440.diff
        8 kB
        Knut Anders Hatlen

        Issue Links

          Activity

          Hide
          Knut Anders Hatlen added a comment -

          Looks similar to DERBY-5278, except it's in another test method. Probably a similar solution is needed for this test method.

          Show
          Knut Anders Hatlen added a comment - Looks similar to DERBY-5278 , except it's in another test method. Probably a similar solution is needed for this test method.
          Hide
          Knut Anders Hatlen added a comment -

          The attached patch changes the test case in a way similar to DERBY-5278 to provide better synchronization between the main test thread and the helper thread. It adds a barrier to ensure that the main thread has started the index scan before the helper thread inserts new rows at the beginning of the index (the problem in this bug seems to be that the rows have been inserted before the scan started, and they unexpectedly show up in the scan result).

          A helper class called Barrier is introduced (java.util.concurrent.CyclicBarrier provides the same functionality, but cannot be used since it requires Java 5), and the patch rewrites the fix for DERBY-5278 to use the new helper class too.

          Show
          Knut Anders Hatlen added a comment - The attached patch changes the test case in a way similar to DERBY-5278 to provide better synchronization between the main test thread and the helper thread. It adds a barrier to ensure that the main thread has started the index scan before the helper thread inserts new rows at the beginning of the index (the problem in this bug seems to be that the rows have been inserted before the scan started, and they unexpectedly show up in the scan result). A helper class called Barrier is introduced (java.util.concurrent.CyclicBarrier provides the same functionality, but cannot be used since it requires Java 5), and the patch rewrites the fix for DERBY-5278 to use the new helper class too.
          Hide
          Knut Anders Hatlen added a comment -

          Attaching an updated version of the patch. It improves some of the comments, and also moves the barrier from right before the index scan has started to the point where the first row has been read from the index. By moving the barrier to that point, we can be absolutely sure that the first row has been seen before the helper thread starts inserting more rows at the beginning of the index (protects against the unlikely event that the first rs.next() call takes more than a second).

          Show
          Knut Anders Hatlen added a comment - Attaching an updated version of the patch. It improves some of the comments, and also moves the barrier from right before the index scan has started to the point where the first row has been read from the index. By moving the barrier to that point, we can be absolutely sure that the first row has been seen before the helper thread starts inserting more rows at the beginning of the index (protects against the unlikely event that the first rs.next() call takes more than a second).
          Hide
          Knut Anders Hatlen added a comment -

          Committed to trunk with revision 1181756.
          Committed to 10.8 with revision 1181761.

          Show
          Knut Anders Hatlen added a comment - Committed to trunk with revision 1181756. Committed to 10.8 with revision 1181761.
          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:
              Knut Anders Hatlen
              Reporter:
              Myrna van Lunteren
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development