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] Commented: (DERBY-4667) BootLockTest.testBootLock() sometimes fails with connection refused.
Date Wed, 26 May 2010 00:49:32 GMT

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

Kathey Marsden commented on DERBY-4667:
---------------------------------------

Mamta, do you have the test directory of a failing run?    If so, might there be some clues
in there as to the reason for the failure, like something in the derby.log?  Otherwise could
we add more debug information in the event of a failure?


> 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.


Mime
View raw message