[
https://issues.apache.org/jira/browse/DERBY-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12870123#action_12870123
]
Kathey Marsden commented on DERBY-4667:
---------------------------------------
Below are my brief and somewhat random thoughts on this issue.
- My gut feel is that this is some sort of firewall interference. If someone
can reproduce, you might want to turn your firewall off to verify.
- The test coordinates launch of a spawned process with a socket, but it
actually uses the same port as network server and the java in $JAVA_HOME/bin so
while it feels like a firewall issue, I am don't really understand why the
firewall would complain.
- Mike suggested a previous tests network server process might be interfering
and the port reused too quickly but I think if the previous tests network
server did a clean shutdown that should not be the problem.
- I thought maybe the test could instead of opening a socket, verify that the
spawned test had booted derby by just checking for the lock file, but if that
is the solution, it would be good to understand first why the socket solution
sometimes fails.
> BootLockTest.testBootLock() sometimes fails with connection refused.
> ---------------------------------------------------------------------
>
> Key: DERBY-4667
> URL: https://issues.apache.org/jira/browse/DERBY-4667
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.6.1.0
> Reporter: Kathey Marsden
>
> It may just be related to firewall interference, but sometimes testBootLock
> fails with:
> 1)
> testBootLock(org.apache.derbyTesting.functionTests.tests.store.BootLockTest)j
> unit.framework.AssertionFailedError: Minion did not start or boot db in 60
> secon
> ds.
> ----Minion's stderr:
> java.net.ConnectException: Connection refused: connect at
> java.net.PlainSocketI
> mpl.socketConnect(Native Method) at
> java.net.PlainSocketImpl.doConnect(Pl
> ainSocketImpl.java:352) at
> java.net.PlainSocketImpl.connectToAddress(PlainSocket
> Impl.java:214) at
> java.net.PlainSocketImpl.connect(PlainSocketImpl.java:201)at
> java.net.SocksSocketImpl.connect(SocksSocketImpl.java:378) at
> java.net.Sock
> et.connect(Socket.java:537) at java.net.Socket.connect(Socket.java:487)
> ----Minion's stderr ended
> at
> org.apache.derbyTesting.functionTests.tests.store.BootLockTest.testBo
> otLock(BootLockTest.java:173)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:48)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:37)
> at
> org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:
> 109)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> at junit.extensions.TestSetup.run(TestSetup.java:16)
> at
> org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57
> )
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> at junit.extensions.TestSetup.run(TestSetup.java:16)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> at junit.extensions.TestSetup.run(TestSetup.java:16)
> It used to pass on my machine, but I got this today and I think the IBM
> nightly runs have been hitting the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
