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-5192) Setting up network server for management tests hangs intermittently
Date Fri, 15 Apr 2011 10:44:05 GMT

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

Knut Anders Hatlen commented on DERBY-5192:
-------------------------------------------

I tested the patch manually the following way:

1) In blockingStart(), I added a 20 second sleep right before the synchronized block around
the wait() call.

2) Started a network server using the CLI.

3) While blockingStart() was in the 20 second sleep, shut down the network server using the
CLI.

4) Ping the network server using the CLI.

What I observed was:

I) Without the patch: The shutdown command in (3) would complete successfully. However, the
network server process would continue running. The first ping in (4) would fail with a "connection
reset" error. Subsequent pings would hang indefinitely.

II) With the patch: The shutdown command in (3) completed successfully, and the network server
process would terminate once the 20 second sleep was completed. When pinging the network server
after the shutdown, a "connection reset" error was seen. Subsequent pings would hang until
the 20 second sleep was completed and then fail with a "connection reset" error. Pinging the
server after the server process had terminated failed with "connection refused".

So, in short: Without the patch, the server isn't properly shut down, and incoming connection
attempts will hang indefinitely. With the patch, the server is shut down, and incoming connection
attempts will fail instead of hanging.

> Setting up network server for management tests hangs intermittently
> -------------------------------------------------------------------
>
>                 Key: DERBY-5192
>                 URL: https://issues.apache.org/jira/browse/DERBY-5192
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Server
>    Affects Versions: 10.8.1.1
>         Environment: Derby 10.8.1.0 - FreeBSD 8.2 (i386) - OpenJDK 6 (b20)
> Derby 10.8.1.0 - Oracle Enterprise Linux 6.0 (x86_64) - OpenJDK 6 (b17)
> Derby 10.8.1.1 - Debian GNU/Linux 6.0.1 (i386) - JDK 7 (build 1.7.0-ea-b135)
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>         Attachments: wait-notify.diff
>
>
> I've seen on three occurrences with the 10.8.1.0 and 10.8.1.1 release candidates that
suites.All has been stuck when setting up the network server decorator for the management
test suite. Here's what I see at the end of the console output (running with derby.tests.trace=true):
>     [junit] test_jdbc4_1 used 0 ms 
>     [junit] test_jdbc4_1 used 0 ms 
>     [junit] test_notBooted used 1623 ms java.net.SocketException: Connection reset
>     [junit] 	at java.net.SocketInputStream.read(SocketInputStream.java:189)
>     [junit] 	at java.net.SocketInputStream.read(SocketInputStream.java:121)
>     [junit] 	at java.net.SocketInputStream.read(SocketInputStream.java:107)
>     [junit] 	at org.apache.derby.impl.drda.NetworkServerControlImpl.fillReplyBuffer(Unknown
Source)
>     [junit] 	at org.apache.derby.impl.drda.NetworkServerControlImpl.readResult(Unknown
Source)
>     [junit] 	at org.apache.derby.impl.drda.NetworkServerControlImpl.pingWithNoOpen(Unknown
Source)
>     [junit] 	at org.apache.derby.impl.drda.NetworkServerControlImpl.ping(Unknown Source)
>     [junit] 	at org.apache.derby.drda.NetworkServerControl.ping(Unknown Source)
>     [junit] 	at org.apache.derbyTesting.junit.NetworkServerTestSetup.pingForServerUp(NetworkServerTestSetup.java:567)
>     [junit] 	at org.apache.derbyTesting.junit.NetworkServerTestSetup.pingForServerStart(NetworkServerTestSetup.java:636)
>     [junit] 	at org.apache.derbyTesting.junit.NetworkServerTestSetup.setUp(NetworkServerTestSetup.java:196)
>     [junit] 	at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
>     [junit] 	at junit.framework.TestResult.runProtected(TestResult.java:124)
>     [junit] 	at junit.extensions.TestSetup.run(TestSetup.java:25)
>     [junit] 	at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
>     [junit] 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>     [junit] 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>     [junit] 	at junit.framework.TestResult.runProtected(TestResult.java:124)
>     [junit] 	at junit.extensions.TestSetup.run(TestSetup.java:25)
>     [junit] 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
>     [junit] 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>     [junit] 	at junit.framework.TestResult.runProtected(TestResult.java:124)
>     [junit] 	at junit.extensions.TestSetup.run(TestSetup.java:25)
>     [junit] 	at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
>     [junit] 	at junit.framework.TestSuite.runTest(TestSuite.java:230)
>     [junit] 	at junit.framework.TestSuite.run(TestSuite.java:225)
>     [junit] 	at junit.framework.TestSuite.runTest(TestSuite.java:230)
>     [junit] 	at junit.framework.TestSuite.run(TestSuite.java:225)
>     [junit] 	at junit.framework.TestSuite.runTest(TestSuite.java:230)
>     [junit] 	at junit.framework.TestSuite.run(TestSuite.java:225)
>     [junit] 	at junit.framework.TestSuite.runTest(TestSuite.java:230)
>     [junit] 	at junit.framework.TestSuite.run(TestSuite.java:225)
>     [junit] 	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:518)
>     [junit] 	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1052)
>     [junit] 	at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:906)
> The exception trace is just printed to the console, but it doesn't make any test fail.
(The exception printed on FreeBSD was different, it said "DRDA_InvalidReplyTooShort.S:Invalid
reply from network server: Insufficient data." The other two looked like the one above.)
> All the hangs have happened on VirtualBox instances, though with different guest operating
systems and JVMs. Probably the timing is different from what we have on physical machines.

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

Mime
View raw message