Derby
  1. Derby
  2. DERBY-1789

'FAIL -- derby.system.durability=test mode seems to be broken.' in store/TestDurabilityProperty.java

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Cannot Reproduce
    • Affects Version/s: 10.2.1.6
    • Fix Version/s: None
    • Component/s: Test
    • Labels:
      None
    • Environment:
      Host: 2 X i86pc i386 (AMD Opteron(tm) Processor 250): 2388 MHz, unknown cache. 2048 Megabytes Total Memory.
      OS: Solaris Nevada snv_43 X86 64 bits - SunOS 5.11 snv_43
      JVM: Sun Microsystems Inc. 1.4.2_05
    • Bug behavior facts:
      Regression Test Failure

      Description

      Diff says:
      "> FAIL – derby.system.durability=test mode seems to be broken.
      > – In this mode one would expect that inserts with autocommit off and on would be in the same range as syncs are not happening but the difference here seems to be more than the approximate estimated range.
      > – Also comparing the time taken to do the inserts without this property set seems to be in the same range as with this property set.
      > – Please note this test times inserts and approximate estimates were considered to report this observation.
      Test Failed.
      "

      Could this be caused by other high load on the machine? Not that I can confirm that this happended here though.

      Log: http://www.multinet.no/~solberg/public/Apache/10.2.1.1_RC/jvm1.4/testlog/solN+1/436991-derbyall_diff.txt

        Issue Links

          Activity

          Hide
          Rajesh Kartha added a comment -

          Not sure what went wrong here.
          I have been running tests on Linux and Windows with java 142 and 15 and am yet to see this failure. Is anybody
          else seeing this ?

          Show
          Rajesh Kartha added a comment - Not sure what went wrong here. I have been running tests on Linux and Windows with java 142 and 15 and am yet to see this failure. Is anybody else seeing this ?
          Hide
          Sunitha Kambhampati added a comment -

          >Could this be caused by other high load on the machine? Not that I can confirm that this happended here though.

          Yes. This is more of a performance test. This test uses an approximation to test whether the inserts went faster with this property enabled versus when it is not enabled.

          I briefly looked at the report at http://www.multinet.no/~solberg/public/Apache/#TenTwoZeroSnapshots and I dont see this test failing there. (btw - Very helpful summary report. - Thanks for the great work, Ole.).

          If you can confirm this test is not failing, then it may be ok to close this issue. Thanks.

          Show
          Sunitha Kambhampati added a comment - >Could this be caused by other high load on the machine? Not that I can confirm that this happended here though. Yes. This is more of a performance test. This test uses an approximation to test whether the inserts went faster with this property enabled versus when it is not enabled. I briefly looked at the report at http://www.multinet.no/~solberg/public/Apache/#TenTwoZeroSnapshots and I dont see this test failing there. (btw - Very helpful summary report. - Thanks for the great work, Ole.). If you can confirm this test is not failing, then it may be ok to close this issue. Thanks.
          Hide
          Stefan Cordes added a comment -

          We use the derby.system.durability=test property for doing a kind of bulk database copy (with data coming out of z/OS DB2).

          With the official released version 10.2.1.6 the inserts are 9 times slower that in 10.1.2.2 (370021).
          With 10.2 it took 44 minutes, with 10.1 only 5 minutes.

          So I can confirm this bug.

          (Derby 10.2 did write 31 log files (log31.dat) and 10.1 did, too)

          Show
          Stefan Cordes added a comment - We use the derby.system.durability=test property for doing a kind of bulk database copy (with data coming out of z/OS DB2). With the official released version 10.2.1.6 the inserts are 9 times slower that in 10.1.2.2 (370021). With 10.2 it took 44 minutes, with 10.1 only 5 minutes. So I can confirm this bug. (Derby 10.2 did write 31 log files (log31.dat) and 10.1 did, too)
          Hide
          Stefan Cordes added a comment -

          Time differences above are not caused by derby.system.durability=test but by different CPU assignment between Eclipse 3.1.2 and the running program when in debug mode. Details follow later.

          Show
          Stefan Cordes added a comment - Time differences above are not caused by derby.system.durability=test but by different CPU assignment between Eclipse 3.1.2 and the running program when in debug mode. Details follow later.
          Hide
          Kathey Marsden added a comment -

          I wonder if this issue can be closed. I don't recall this test failing recently. The user who thought there might be a problem with derby.system.durability indicated that the problem was due to other issues.

          Show
          Kathey Marsden added a comment - I wonder if this issue can be closed. I don't recall this test failing recently. The user who thought there might be a problem with derby.system.durability indicated that the problem was due to other issues.
          Hide
          Ole Solberg added a comment -

          Closing as "Cannot Reproduce" as this has not been seen in a long time.

          Show
          Ole Solberg added a comment - Closing as "Cannot Reproduce" as this has not been seen in a long time.
          Hide
          Mamta A. Satoor added a comment -

          This test failed on one of the Linux/VMware machine running top of the trunk 10.10.0.0 alpha - (1352388) with ibm17. The failure is as follows
          Failure Details:

                          • Diff file derbyall/storeall/storemore/TestDurabilityProperty.diff
              • Start: TestDurabilityProperty jdk1.7.0 storeall:storemore 2012-06-21 00:59:44 ***
                1a2,5
                > FAIL – derby.system.durability=test mode seems to be broken.
                > – In this mode one would expect that inserts with autocommit off and on would be in the same range as syncs are not happening but the difference here seems to be more than the approximate estimated range.
                > – Also comparing the time taken to do the inserts without this property set seems to be in the same range as with this property set.
                > – Please note this test times inserts and approximate estimates were considered to report this observation.
                Test Failed.
              • End: TestDurabilityProperty jdk1.7.0 storeall:storemore 2012-06-21 01:00:37 ***

          Java version - JRE 1.7.0 IBM J9 2.6 Linux x86-32 20110810_88604 (JIT enabled, AOT enabled)

          Show
          Mamta A. Satoor added a comment - This test failed on one of the Linux/VMware machine running top of the trunk 10.10.0.0 alpha - (1352388) with ibm17. The failure is as follows Failure Details: Diff file derbyall/storeall/storemore/TestDurabilityProperty.diff Start: TestDurabilityProperty jdk1.7.0 storeall:storemore 2012-06-21 00:59:44 *** 1a2,5 > FAIL – derby.system.durability=test mode seems to be broken. > – In this mode one would expect that inserts with autocommit off and on would be in the same range as syncs are not happening but the difference here seems to be more than the approximate estimated range. > – Also comparing the time taken to do the inserts without this property set seems to be in the same range as with this property set. > – Please note this test times inserts and approximate estimates were considered to report this observation. Test Failed. End: TestDurabilityProperty jdk1.7.0 storeall:storemore 2012-06-21 01:00:37 *** Java version - JRE 1.7.0 IBM J9 2.6 Linux x86-32 20110810_88604 (JIT enabled, AOT enabled)

            People

            • Assignee:
              Unassigned
              Reporter:
              Ole Solberg
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development