Derby
  1. Derby
  2. DERBY-5144

Intermittent "connection refused" errors in the compatibility tests

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 10.8.1.2
    • Fix Version/s: None
    • Component/s: Test
    • Labels:
      None
    • Environment:
      Compatibility tests on Linux.
      Sun Java 1.5.0, 1.6.0.
    • Bug behavior facts:
      Regression Test Failure

      Description

      The compatibility tests fail intermittently with connection refused errors. I've only seen it happening on Linux so far.

      Example failures:

      http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/testlog/lin/902174-compatibility_diff.txt
      http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/testlog/sles/1079439-compatibility_diff.txt
      http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/testlog/sles/1080669-compatibility_diff.txt
      http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/testlog/sles/1081468-compatibility_diff.txt
      http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/testlog/lin/1083233-compatibility_diff.txt

      The stack trace always looks like this:

      Exception in thread "main" com.ibm.db2.jcc.c.SqlException: java.net.ConnectException : Error opening socket to server localhost on port 1527 with message : Connection refused
      at com.ibm.db2.jcc.a.a.<init>(a.java:135)
      at com.ibm.db2.jcc.a.b.a(b.java:1542)
      at com.ibm.db2.jcc.c.o.<init>(o.java:795)
      at com.ibm.db2.jcc.a.b.<init>(b.java:298)
      at com.ibm.db2.jcc.DB2Driver.connect(DB2Driver.java:162)
      at java.sql.DriverManager.getConnection(DriverManager.java:582)
      at java.sql.DriverManager.getConnection(DriverManager.java:154)
      at org.apache.derbyTesting.functionTests.util.DerbyJUnitTest.createDB(DerbyJUnitTest.java:416)
      at org.apache.derbyTesting.functionTests.tests.junitTests.compatibility.CompatibilitySuite.access$000(CompatibilitySuite.java:41)
      at org.apache.derbyTesting.functionTests.tests.junitTests.compatibility.CompatibilitySuite$Creator.main(CompatibilitySuite.java:448)

      The actual combination in which it fails varies. The reports mentioned above show failures in these combinations:

      jdk1.5 + server 10.1.3.1
      jdk1.6 + server 10.1.3.1
      jdk1.6 + server 10.5.1.1
      jdk1.5 + server 10.0.2.1
      jdk1.5 + server 10.7.1.1

      The client that fails is always JCC, but that's because it's always the first client to be tested on each server version.

        Issue Links

          Activity

          Hide
          Knut Anders Hatlen added a comment -

          This still hasn't happened after DERBY-5222 was fixed, so I'm closing it as a duplicate. If it happens again, we can reopen the bug or file a new one.

          Show
          Knut Anders Hatlen added a comment - This still hasn't happened after DERBY-5222 was fixed, so I'm closing it as a duplicate. If it happens again, we can reopen the bug or file a new one.
          Hide
          Knut Anders Hatlen added a comment -

          The root cause of this bug may be the same as DERBY-5222. There we saw that the compatibility tests didn't wait for forked processes to complete before continuing with the next combination. So there is a possibility that an old server process is preventing the new server from starting, which could cause symptoms similar to those we see here (connection refused).

          Show
          Knut Anders Hatlen added a comment - The root cause of this bug may be the same as DERBY-5222 . There we saw that the compatibility tests didn't wait for forked processes to complete before continuing with the next combination. So there is a possibility that an old server process is preventing the new server from starting, which could cause symptoms similar to those we see here (connection refused).
          Hide
          Knut Anders Hatlen added a comment -
          Show
          Knut Anders Hatlen added a comment - Also seen with the 10.8.1.2 release candidate: http://dbtg.foundry.sun.com/derby/test/10.8.1.2_RC/logs/jvm1.7-64/sles/compatibility/report.txt
          Hide
          Knut Anders Hatlen added a comment -

          After disabling JCC in the tests, the problem is still seen, only that it's now moved to the Derby client driver:

          Exception in thread "main" org.apache.derby.client.am.DisconnectException: java.net.ConnectException : Error opening socket to server localhost on port 1527 with message : Connection refused
          at org.apache.derby.client.net.NetAgent.<init>(Unknown Source)
          at org.apache.derby.client.net.NetConnection.newAgent_(Unknown Source)
          at org.apache.derby.client.am.Connection.<init>(Unknown Source)
          at org.apache.derby.client.net.NetConnection.<init>(Unknown Source)
          at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
          at java.sql.DriverManager.getConnection(DriverManager.java:512)
          at java.sql.DriverManager.getConnection(DriverManager.java:140)
          at org.apache.derbyTesting.functionTests.util.DerbyJUnitTest.createDB(DerbyJUnitTest.java:416)
          at org.apache.derbyTesting.functionTests.tests.junitTests.compatibility.CompatibilitySuite.access$000(CompatibilitySuite.java:41)
          at org.apache.derbyTesting.functionTests.tests.junitTests.compatibility.CompatibilitySuite$Creator.main(CompatibilitySuite.java:448)

          http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/testlog/lin/1084638-compatibility_diff.txt

          Show
          Knut Anders Hatlen added a comment - After disabling JCC in the tests, the problem is still seen, only that it's now moved to the Derby client driver: Exception in thread "main" org.apache.derby.client.am.DisconnectException: java.net.ConnectException : Error opening socket to server localhost on port 1527 with message : Connection refused at org.apache.derby.client.net.NetAgent.<init>(Unknown Source) at org.apache.derby.client.net.NetConnection.newAgent_(Unknown Source) at org.apache.derby.client.am.Connection.<init>(Unknown Source) at org.apache.derby.client.net.NetConnection.<init>(Unknown Source) at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source) at java.sql.DriverManager.getConnection(DriverManager.java:512) at java.sql.DriverManager.getConnection(DriverManager.java:140) at org.apache.derbyTesting.functionTests.util.DerbyJUnitTest.createDB(DerbyJUnitTest.java:416) at org.apache.derbyTesting.functionTests.tests.junitTests.compatibility.CompatibilitySuite.access$000(CompatibilitySuite.java:41) at org.apache.derbyTesting.functionTests.tests.junitTests.compatibility.CompatibilitySuite$Creator.main(CompatibilitySuite.java:448) http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/testlog/lin/1084638-compatibility_diff.txt
          Hide
          Knut Anders Hatlen added a comment -

          I've disabled the testing against JCC in the nightly tests for now, so that we can eliminate that it's causing the problems. Unfortunately, one cannot disable JCC testing without also disabling testing of the 10.0 version of the network server.

          Show
          Knut Anders Hatlen added a comment - I've disabled the testing against JCC in the nightly tests for now, so that we can eliminate that it's causing the problems. Unfortunately, one cannot disable JCC testing without also disabling testing of the 10.0 version of the network server.
          Hide
          Kathey Marsden added a comment -

          I would suggest removing JCC from the testing as it has not been supported by IBM with Derby since 10.1.

          Show
          Kathey Marsden added a comment - I would suggest removing JCC from the testing as it has not been supported by IBM with Derby since 10.1.

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development