[
https://issues.apache.org/jira/browse/DERBY-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-4667:
----------------------------------
Attachment: BootLockTestFailure.zip
I am attaching the output from this failure when it once happened.
The interesting things I noticed are:
1) The BootLockTestDB database got created just fine by the forked process at
2010-06-02 09:25:34.284 GMT
2) The last thing in the parent process (derby.log) were a start and stop of
network server at:
2010-06-02 09:25:32.862 GMT : Apache Derby Network Server - 10.7.0.0 alpha -
(949333) started and ready to accept connections on port 1527
2010-06-02 09:25:33.268 GMT : Apache Derby Network Server - 10.7.0.0 alpha -
(949333) shutdown
My impression is that even though the test is not running any fixtures in
network sever mode it is starting and stopping network server for some reason
and doing so, so close to the time that the port is being used for the
synchronization that it interferes. I'll take a look at the test.
> 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
> Attachments: BootLockTestFailure.zip
>
>
> 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.
