db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5144) Intermittent "connection refused" errors in the compatibility tests
Date Wed, 18 May 2011 12:03:47 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13035327#comment-13035327

Knut Anders Hatlen commented on DERBY-5144:

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).

> Intermittent "connection refused" errors in the compatibility tests
> -------------------------------------------------------------------
>                 Key: DERBY-5144
>                 URL: https://issues.apache.org/jira/browse/DERBY-5144
>             Project: Derby
>          Issue Type: Bug
>          Components: Test
>    Affects Versions:
>         Environment: Compatibility tests on Linux.
> Sun Java 1.5.0, 1.6.0.
>            Reporter: Knut Anders Hatlen
> 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
>   jdk1.6 + server
>   jdk1.6 + server
>   jdk1.5 + server
>   jdk1.5 + server
> The client that fails is always JCC, but that's because it's always the first client
to be tested on each server version.

This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message