[
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
