Derby
  1. Derby
  2. DERBY-1399

DerbyNetAutoStart test fails on JDK 1.6 after introduction JDBC4 driver autoloading

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.2.1.6
    • Fix Version/s: 10.2.1.6
    • Component/s: Test
    • Labels:
      None
    • Environment:
      Sun JDK 1.6

      Description

      DerbyNetAutoStart.java fails when running on JDK 1.6 with DerbyNet and DerbyClient frameworks with the following error:

      Starting test case 1.
      Could not access database through the network server.
      java.net.ConnectException : Error connecting to server localhost on port 152
      7 with message Connection refused.
      Starting test case 2.
      Could not access database through the network server.
      java.net.ConnectException : Error connecting to server localhost on port 314
      15 with message Connection refused.
      Starting test case 3.
      Starting test case 4.
      Starting test case 5.
      FAILED.

      This test seems to have failed consistently since JDBC4 driver autoloading was introduced (see DERBY-930).

      1. autoload.diff
        2 kB
        Olav Sandstaa

        Issue Links

          Activity

          Hide
          Olav Sandstaa added a comment -

          This problem is similar to the problem that caused the NIST tests to
          fail when running with JDK 1.6 (see DERBY-1379).

          The DerbyNetAutoStart test does the following during start up:

          1. Explicitly load the DerbyNetClient by calling
          TestUtil.loadDriver(). Due to JDBC driver autoloading, this will
          also load the embedded JDBC driver and the Derby engine when
          running with JDK 1.6.

          2. Set some properties for the embedded driver. In the first test
          case this property is:

          derby.drda.startNetworkServer=true

          to make the network server start as part of loading the embedded driver.

          3. Explicitly load the embedded driver. But since the driver and
          engine are already loaded, not much is done here. As a
          consequence the properties set does not take effect, and the
          network server is not started. This makes the test fail.

          I plan to fix this problem by explicitly attempt to unload the
          embedded driver and engine in the start of each individual subtest.
          (This is already done after each sub test has run, but this does not
          help the first subtest).

          Show
          Olav Sandstaa added a comment - This problem is similar to the problem that caused the NIST tests to fail when running with JDK 1.6 (see DERBY-1379 ). The DerbyNetAutoStart test does the following during start up: 1. Explicitly load the DerbyNetClient by calling TestUtil.loadDriver(). Due to JDBC driver autoloading, this will also load the embedded JDBC driver and the Derby engine when running with JDK 1.6. 2. Set some properties for the embedded driver. In the first test case this property is: derby.drda.startNetworkServer=true to make the network server start as part of loading the embedded driver. 3. Explicitly load the embedded driver. But since the driver and engine are already loaded, not much is done here. As a consequence the properties set does not take effect, and the network server is not started. This makes the test fail. I plan to fix this problem by explicitly attempt to unload the embedded driver and engine in the start of each individual subtest. (This is already done after each sub test has run, but this does not help the first subtest).
          Hide
          Bryan Pendleton added a comment -

          Could we just take out that very first call to TestUtil.loadDriver()?
          It isn't obvious why that call is there; perhaps it doesn't need to be.

          Show
          Bryan Pendleton added a comment - Could we just take out that very first call to TestUtil.loadDriver()? It isn't obvious why that call is there; perhaps it doesn't need to be.
          Hide
          Olav Sandstaa added a comment -

          Bryan, thanks for commenting on this issue.

          The call to TestUtil.loadDriver() needs to be in the test. This method loads the Derby client driver (or the JCC driver when running in the DerbyNet framework). The client driver is used in the test to establish connections to the network server. Without explicitly loading a client driver the test will fail with "No suitable driver" when attempting to connect (at least when running with a pre JDK 1.6 VM).

          The DerbyNetAutoStart test loads both a client driver (Derby client driver or JCC) and the embedded driver (with or without starting the network server).

          Show
          Olav Sandstaa added a comment - Bryan, thanks for commenting on this issue. The call to TestUtil.loadDriver() needs to be in the test. This method loads the Derby client driver (or the JCC driver when running in the DerbyNet framework). The client driver is used in the test to establish connections to the network server. Without explicitly loading a client driver the test will fail with "No suitable driver" when attempting to connect (at least when running with a pre JDK 1.6 VM). The DerbyNetAutoStart test loads both a client driver (Derby client driver or JCC) and the embedded driver (with or without starting the network server).
          Hide
          Olav Sandstaa added a comment -

          This patch fixes the problem with the embedded driver being autoloaded before all Derby properties have been defined by explicitly unloading the embedded driver in the start of each sub test.

          I have run derbyall on Sun JDK 1.5 and 1.6 with only the usual tests failing.

          svn status reports:

          M java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/DerbyNetAutoStart.java

          The patch is ready for review and commit.

          Show
          Olav Sandstaa added a comment - This patch fixes the problem with the embedded driver being autoloaded before all Derby properties have been defined by explicitly unloading the embedded driver in the start of each sub test. I have run derbyall on Sun JDK 1.5 and 1.6 with only the usual tests failing. svn status reports: M java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/DerbyNetAutoStart.java The patch is ready for review and commit.
          Hide
          Kathey Marsden added a comment -

          I am very concerned that the patch for this issue is for the test and not the product. It is a red flag for me that existing applications could be impacted by the code change.

          Could you summarize the justification for the test change to resolve this issue.

          Show
          Kathey Marsden added a comment - I am very concerned that the patch for this issue is for the test and not the product. It is a red flag for me that existing applications could be impacted by the code change. Could you summarize the justification for the test change to resolve this issue.
          Hide
          Rick Hillegas added a comment -

          I'm afraid that even with this patch, I'm still seeing the following diff in the DerbyNetAutoStart test when run under mustang build 86 of jdk1.6:

              • Start: DerbyNetAutoStart jdk1.6.0-rc DerbyNet derbynetmats:derbynetmats 2006-06-14 14:44:00 ***
                2a3,6
                > SQL Exception: Java exception: ': org.apache.derby.iapi.services.context.ShutdownException'.
                > Caused by: SQL Exception: Java exception: ': org.apache.derby.iapi.services.context.ShutdownException'.
                > ... 15 more
                > agentThread[DRDAConnThread_8,5,derby.daemons]
                Test Failed.
              • End: DerbyNetAutoStart jdk1.6.0-rc DerbyNet derbynetmats:derbynetmats 2006-06-14 14:44:23 ***
          Show
          Rick Hillegas added a comment - I'm afraid that even with this patch, I'm still seeing the following diff in the DerbyNetAutoStart test when run under mustang build 86 of jdk1.6: Start: DerbyNetAutoStart jdk1.6.0-rc DerbyNet derbynetmats:derbynetmats 2006-06-14 14:44:00 *** 2a3,6 > SQL Exception: Java exception: ': org.apache.derby.iapi.services.context.ShutdownException'. > Caused by: SQL Exception: Java exception: ': org.apache.derby.iapi.services.context.ShutdownException'. > ... 15 more > agentThread [DRDAConnThread_8,5,derby.daemons] Test Failed. End: DerbyNetAutoStart jdk1.6.0-rc DerbyNet derbynetmats:derbynetmats 2006-06-14 14:44:23 ***
          Hide
          Olav Sandstaa added a comment -

          Comments to Kathey's concerns about this patch (or rather the change introduced in DERBY-930):

          Autoloading of JDBC drivers is a new feature required by JDBC4. In
          addition to the support for autoloading added to JDBC4 in DERBY-930,
          the main change is in how new JVMs confirming to Java SE 1.6 treat
          JDBC4 drivers. So this test change has just as much with adjusting to
          new behavior in how JVMs loads drivers as it has to do with the
          changes added to Derby in DERBY-930.

          I have raised my opinion about support for autoloading of JDBC drivers
          in a different mail thread (personally I do not like automagic things
          to happen behind my back even if it is considered "ease of development"), see:

          http://www.nabble.com/Autoloading-of-JDBC-drivers-considered-harmful--t1689676.html)

          Still, autoloading will be a documented and supported feature in Derby
          10.2 (at least it seems so) and in Java SE 1.6, and (to quote from one
          of the emails in this email thread) "Thus this is fully documented
          behavior that any application developer must understand."

          So as long as the embedded Derby driver is loading the Derby engine
          and in some cases also the network server, autoloading of the embedded
          JDBC driver may require applications (and Derby tests) to take this
          into account when upgrading to a 1.6. JVM. This is basically what the
          patch I have suggested do.

          There could have been other solutions to this problem by doing changes
          to Derby. For instance splitting loading of the embedded driver and
          booting of the Derby engine and starting of the network server. Even
          if we decided to do this, this test had to be changed in one way or
          the other in order to get the network server started (it is now
          started by setting the property derby.drda.startNetworkServer=true
          before the embedded driver is loaded). I think splitting of driver
          loading and booting of the engine would be a good thing to implement,
          but right now I do not have the time to take on this task. My itch
          right now is to get this test to run with JDK 1.6 and the change is
          basically to take into account the new behavior that any 1.6 JVM will
          have.

          Show
          Olav Sandstaa added a comment - Comments to Kathey's concerns about this patch (or rather the change introduced in DERBY-930 ): Autoloading of JDBC drivers is a new feature required by JDBC4. In addition to the support for autoloading added to JDBC4 in DERBY-930 , the main change is in how new JVMs confirming to Java SE 1.6 treat JDBC4 drivers. So this test change has just as much with adjusting to new behavior in how JVMs loads drivers as it has to do with the changes added to Derby in DERBY-930 . I have raised my opinion about support for autoloading of JDBC drivers in a different mail thread (personally I do not like automagic things to happen behind my back even if it is considered "ease of development"), see: http://www.nabble.com/Autoloading-of-JDBC-drivers-considered-harmful--t1689676.html ) Still, autoloading will be a documented and supported feature in Derby 10.2 (at least it seems so) and in Java SE 1.6, and (to quote from one of the emails in this email thread) "Thus this is fully documented behavior that any application developer must understand." So as long as the embedded Derby driver is loading the Derby engine and in some cases also the network server, autoloading of the embedded JDBC driver may require applications (and Derby tests) to take this into account when upgrading to a 1.6. JVM. This is basically what the patch I have suggested do. There could have been other solutions to this problem by doing changes to Derby. For instance splitting loading of the embedded driver and booting of the Derby engine and starting of the network server. Even if we decided to do this, this test had to be changed in one way or the other in order to get the network server started (it is now started by setting the property derby.drda.startNetworkServer=true before the embedded driver is loaded). I think splitting of driver loading and booting of the engine would be a good thing to implement, but right now I do not have the time to take on this task. My itch right now is to get this test to run with JDK 1.6 and the change is basically to take into account the new behavior that any 1.6 JVM will have.
          Hide
          Olav Sandstaa added a comment -

          Rick, The failure you see is not related to neither autoloading nor my patch. This problem is reported separately in DERBY-803 and also seen on other platforms than JDK 1.6. My patch did not intend to fix this problem. I have not seen this problem when I run this test.

          Show
          Olav Sandstaa added a comment - Rick, The failure you see is not related to neither autoloading nor my patch. This problem is reported separately in DERBY-803 and also seen on other platforms than JDK 1.6. My patch did not intend to fix this problem. I have not seen this problem when I run this test.
          Hide
          Kathey Marsden added a comment -

          Thanks Olav. I reopened DERBY-930 so a release note can be added descibing the user impact and describe symptoms users might encounter. Then it will be easier for the community to assess if the behavior change is acceptable or this needs to be clasified as a regression. I 'd prefer to not ccommit this patch until that dertermination has been made.

          Show
          Kathey Marsden added a comment - Thanks Olav. I reopened DERBY-930 so a release note can be added descibing the user impact and describe symptoms users might encounter. Then it will be easier for the community to assess if the behavior change is acceptable or this needs to be clasified as a regression. I 'd prefer to not ccommit this patch until that dertermination has been made.
          Hide
          Kathey Marsden added a comment -

          Is this patch still needed, now that DERBY-1459 is fixed? Would it be ok to uncheck patch available?

          Show
          Kathey Marsden added a comment - Is this patch still needed, now that DERBY-1459 is fixed? Would it be ok to uncheck patch available?
          Hide
          Olav Sandstaa added a comment -

          DerbyNetAutoStart runs without problems after DERBY-1459 was fixed. The patch is not needed anymore. I agree that we can uncheck patch available. I will also close the Jira issue since it is no longer an issue.

          Show
          Olav Sandstaa added a comment - DerbyNetAutoStart runs without problems after DERBY-1459 was fixed. The patch is not needed anymore. I agree that we can uncheck patch available. I will also close the Jira issue since it is no longer an issue.
          Hide
          Olav Sandstaa added a comment -

          This patch was never used since autoloading was improved (see DERBY1459) to handle the situation which created problems for the DerbyNetAutoStart thest.

          Show
          Olav Sandstaa added a comment - This patch was never used since autoloading was improved (see DERBY1459) to handle the situation which created problems for the DerbyNetAutoStart thest.
          Hide
          Olav Sandstaa added a comment -

          Fixed as part of DERBY-1459.

          Show
          Olav Sandstaa added a comment - Fixed as part of DERBY-1459 .

            People

            • Assignee:
              Olav Sandstaa
              Reporter:
              Olav Sandstaa
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development