Derby
  1. Derby
  2. DERBY-4898

testGetURL test fails in nightly runs.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.7.1.1
    • Fix Version/s: 10.7.1.1
    • Component/s: Test
    • Labels:
      None
    • Environment:
    • Bug behavior facts:
      Regression Test Failure

      Description

      I saw this failure while running a test with some changes to print better diagnostics on checksum failure, so pretty
      sure had nothing to do with my change. Just from looking at the message it looks likely to be a test issue with something changing the order of the properties.

      There was 1 failure:
      1) testGetURL(org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDa
      taTest)junit.framework.ComparisonFailure: getURL match expected:<...territory=en
      ;collation=TERRITORY_BASED> but was:<...collation=TERRITORY_BASED;territory=en>
      at java.lang.Throwable.<init>(Throwable.java:67)
      at junit.framework.AssertionFailedError.<init>(AssertionFailedError.java:11)
      at junit.framework.ComparisonFailure.<init>(ComparisonFailure.java:19)
      at org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.
      testGetURL(DatabaseMetaDataTest.java:717)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
      :48)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI
      mpl.java:37)
      at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
      at junit.extensions.TestSetup.run(TestSetup.java:23)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
      at junit.extensions.TestSetup.run(TestSetup.java:23)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
      at junit.extensions.TestSetup.run(TestSetup.java:23)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
      at junit.extensions.TestSetup.run(TestSetup.java:23)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
      at junit.extensions.TestSetup.run(TestSetup.java:23)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
      at junit.extensions.TestSetup.run(TestSetup.java:23)

      1. d4898.diff
        5 kB
        Knut Anders Hatlen

        Issue Links

          Activity

          Hide
          Kathey Marsden added a comment -

          Whoever is working on this issue may want to make note of DERBY-4886: Embedded and client differ on whether they return attributes. I am not actually sure which behavior is correct. Also in the past I have seen ordering differences in Properties objects because they extend Hashtable. Different implementations may order these differently. I don't know if in this case the properties on the url are extracted into a Properties object and reconstructed. If so that might explain the order change. It would be good to know the java -version on which this failed.

          Show
          Kathey Marsden added a comment - Whoever is working on this issue may want to make note of DERBY-4886 : Embedded and client differ on whether they return attributes. I am not actually sure which behavior is correct. Also in the past I have seen ordering differences in Properties objects because they extend Hashtable. Different implementations may order these differently. I don't know if in this case the properties on the url are extracted into a Properties object and reconstructed. If so that might explain the order change. It would be good to know the java -version on which this failed.
          Hide
          Knut Anders Hatlen added a comment -

          This failure was likely caused by the changes in DERBY-4884, and happens when DatabaseMetaDataTest is run as part of CollationTest. Not sure why the attributes end up with different order, though. ClientDriver.appendDatabaseAttributes() and TestConfiguration.getConnectionAttributesString() appear to build the attributes part of the URL the same way, and I thought Properties.propertyNames() would order the properties consistently on a single platform.

          Show
          Knut Anders Hatlen added a comment - This failure was likely caused by the changes in DERBY-4884 , and happens when DatabaseMetaDataTest is run as part of CollationTest. Not sure why the attributes end up with different order, though. ClientDriver.appendDatabaseAttributes() and TestConfiguration.getConnectionAttributesString() appear to build the attributes part of the URL the same way, and I thought Properties.propertyNames() would order the properties consistently on a single platform.
          Hide
          Knut Anders Hatlen added a comment -

          Ah, right... It's not the same Properties object in the two cases. The framework always adds user=APP and password=APP before connecting (but ClientDriver.appendDatabaseAttributes() suppresses those properties – DERBY-559 – so they don't show up in getURL()), so the two objects represent different sets of properties and the ordering may differ.

          Show
          Knut Anders Hatlen added a comment - Ah, right... It's not the same Properties object in the two cases. The framework always adds user=APP and password=APP before connecting (but ClientDriver.appendDatabaseAttributes() suppresses those properties – DERBY-559 – so they don't show up in getURL()), so the two objects represent different sets of properties and the ordering may differ.
          Hide
          Mamta A. Satoor added a comment -

          Seems like we are close to finding the root of the problem. I just wanted to share that I saw the same failure repeatedly on my windows xp laptop running against trunk with ibm16 jvm

          $ java -version
          java version "1.6.0"
          Java(TM) SE Runtime Environment (build pwi3260sr6-20090925_01(SR6))
          IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260sr6-200909
          23_42924 (JIT enabled, AOT enabled)
          J9VM - 20090923_042924
          JIT - r9_20090902_1330ifx1
          GC - 20090817_AA)
          JCL - 20090924_01

          Show
          Mamta A. Satoor added a comment - Seems like we are close to finding the root of the problem. I just wanted to share that I saw the same failure repeatedly on my windows xp laptop running against trunk with ibm16 jvm $ java -version java version "1.6.0" Java(TM) SE Runtime Environment (build pwi3260sr6-20090925_01(SR6)) IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260sr6-200909 23_42924 (JIT enabled, AOT enabled) J9VM - 20090923_042924 JIT - r9_20090902_1330ifx1 GC - 20090817_AA) JCL - 20090924_01
          Hide
          Knut Anders Hatlen added a comment -

          I haven't been able to reproduce this failure in my environment, but I believe the attached patch solves the problem with the ordering. Committed revision 1033851.

          Show
          Knut Anders Hatlen added a comment - I haven't been able to reproduce this failure in my environment, but I believe the attached patch solves the problem with the ordering. Committed revision 1033851.
          Hide
          Knut Anders Hatlen added a comment -

          [bulk update] Close all resolved issues that haven't been updated for more than one year.

          Show
          Knut Anders Hatlen added a comment - [bulk update] Close all resolved issues that haven't been updated for more than one year.

            People

            • Assignee:
              Knut Anders Hatlen
              Reporter:
              Mike Matrigali
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development