db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4667) BootLockTest.testBootLock() sometimes fails with connection refused.
Date Wed, 02 Jun 2010 23:21:56 GMT

     [ https://issues.apache.org/jira/browse/DERBY-4667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Kathey Marsden updated DERBY-4667:
----------------------------------

    Attachment: reorgDerby151TestForDerby4667_diff.txt

I think the quick start and stop of network server is from the previous test Derby151Test,
which has just one fixture which doesn't actually run on the IBM jvm, because of DERBY-4463.
 I am moving the vm logic outside of the fixture to avoid this and will let the IBM run, run
tonight as I am curious if that is causing the problem.




> 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, reorgDerby151TestForDerby4667_diff.txt
>
>
> 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.


Mime
View raw message