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

          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open In Progress In Progress
          14h 42m 1 Knut Anders Hatlen 11/Nov/10 09:11
          In Progress In Progress Resolved Resolved
          14m 51s 1 Knut Anders Hatlen 11/Nov/10 09:26
          Resolved Resolved Closed Closed
          948d 23h 52m 1 Knut Anders Hatlen 17/Jun/13 10:19
          Gavin made changes -
          Workflow jira [ 12526503 ] Default workflow, editable Closed status [ 12797120 ]
          Knut Anders Hatlen made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          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.
          Rick Hillegas made changes -
          Affects Version/s 10.7.1.1 [ 12315564 ]
          Affects Version/s 10.7.1.0 [ 12314971 ]
          Fix Version/s 10.7.1.1 [ 12315564 ]
          Fix Version/s 10.7.1.0 [ 12314971 ]
          Knut Anders Hatlen made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Fix Version/s 10.7.1.0 [ 12314971 ]
          Resolution Fixed [ 1 ]
          Knut Anders Hatlen made changes -
          Attachment d4898.diff [ 12459333 ]
          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.
          Knut Anders Hatlen made changes -
          Link This issue relates to DERBY-4884 [ DERBY-4884 ]
          Knut Anders Hatlen made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Knut Anders Hatlen made changes -
          Assignee Knut Anders Hatlen [ knutanders ]
          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 -

          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
          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.
          Mike Matrigali made changes -
          Field Original Value New Value
          Environment trunk, on a windows xp laptop, against ibm16 jvm, sane build running against classes. trunk, on a windows xp laptop, against ibm16 jvm, sane build running against classes.
          my java version:
          s1_ibm16:5>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
          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.
          Mike Matrigali created issue -

            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