db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3594) socket reset failure causing 17 networkserver tests to fail on ibm iseries
Date Thu, 24 Apr 2008 23:43:56 GMT

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

Myrna van Lunteren updated DERBY-3594:
--------------------------------------

    Component/s:     (was: Regression Test Failure)
                 Test
     Derby Info:   (was: [Regression])

I'm unmarking this as a regression - assuming we interpret regression as code regression,
and adding Test component.

I think the issue is that some new testing code has gone in that has a cut-off time that's
just too fast for my slower machine.
Especially in the class org.apache.derbyTesting.junit.SpawnedProcess there are a number of
Thread.sleep(500) statements - and it's just short.

I have encountered troubles like this before, and I had suggested modifying the code in NetworkServerTestSetup
to default to the current time settings to be configurable...I think Dan at the time voice
concern that there may be a bug hiding. 
I don't think so, and I think at least increasing the number of tries before a timeout is
concluded, would help for NetworkServerTestSetup.

And I think SpawnedProcess needs to have a setup similar to NetworkServerTestSetup where there
are some tries before it is timed out (don't want to have the sleep increase, necessarily,
for that would slow everyone down, even faster machines).



> socket reset failure causing 17 networkserver tests to fail on ibm iseries
> --------------------------------------------------------------------------
>
>                 Key: DERBY-3594
>                 URL: https://issues.apache.org/jira/browse/DERBY-3594
>             Project: Derby
>          Issue Type: Bug
>          Components: Test
>    Affects Versions: 10.4.1.0
>         Environment: IBM iseries, I tried this with a sun 1.4.2 jdk and ibm 1.6 jvm.

>            Reporter: Myrna van Lunteren
>         Attachments: env_report.txt, socketfailures.txt
>
>
> With the beta build for 10.4.1.0 (637204M) I saw 19 failures that I did not see with
10.3.2.1, 17 of which show some kind of timeout due to a socket reset.
> For example:
> 1) SecureServerTest( Opened = false, Authenticated= false, CustomDerbyProperties= null,
WildCardHost= null )junit.framework.AssertionFailedError: Timed out waiting for network server
to start:Spawned SpawnedNetworkServer exitCode=134
> STDERR:
> java.io.IOException: A connection with a remote socket was reset by that socket.
> 	at java.lang.Throwable.<init>(Throwable.java:196)
> 	at java.lang.Exception.<init>(Exception.java:41)
> 	at java.io.IOException.<init>(IOException.java:41)
> 	at java.io.FileInputStream.readBytes(Native Method)
> 	at java.io.FileInputStream.read(FileInputStream.java:177)
> 	at org.apache.derbyTesting.junit.SpawnedProcess$2.run(SpawnedProcess.java:179)
> 	at java.lang.Thread.run(Thread.java:619)
> STDOUT:
> java.io.IOException: A connection with a remote socket was reset by that socket.
> 	at java.lang.Throwable.<init>(Throwable.java:196)
> 	at java.lang.Exception.<init>(Exception.java:41)
> 	at java.io.IOException.<init>(IOException.java:41)
> 	at java.io.FileInputStream.readBytes(Native Method)
> 	at java.io.FileInputStream.read(FileInputStream.java:199)
> 	at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
> 	at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)
> 	at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
> 	at java.io.FilterInputStream.read(FilterInputStream.java:90)
> 	at org.apache.derbyTesting.junit.SpawnedProcess$2.run(SpawnedProcess.java:179)
> 	at java.lang.Thread.run(Thread.java:619)
> 	at java.lang.Throwable.<init>(Throwable.java:196)
> 	at java.lang.Error.<init>(Error.java:49)
> 	at junit.framework.AssertionFailedError.<init>(AssertionFailedError.java:11)
> 	at org.apache.derbyTesting.junit.NetworkServerTestSetup.setUp(NetworkServerTestSetup.java:196)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:18)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> 	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:23)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> I saw no useful information in derby.log files, it could be that there is some authentication
issue playing here.

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