db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-2616) intermittent network startup related errors in running junit nightly test suite
Date Sat, 05 May 2007 18:02:15 GMT

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

Mike Matrigali updated DERBY-2616:

I noticed that netstat -a reported a lot of  ports for the server were in TIME_WAIT, and I
found that default TIME_WAIT on XP
is 240 seconds.  I also found the following on the net about TIME_WAIT and am wondering if
either the test or the server
is forcing a artificially small port space and thus causing this wait time:

TIME_WAIT is an integral part of TCP's correctness algorithms. It is
there to protect new connections by the same "name" from inadvertently
accepting segments from old connections and thus corrupting data.

Strictly speaking, TIME_WAIT is supposed to last as long as four
minutes, so the connection rate that could result in attempts to reuse
a TCP connection name (local/remote IP, local/remote port) that is
still in TIME_WAIT would be:


If your client application is allowing the stack to pick the local
port number (eg is not calling bind() to pick a port number itself),
then likely as not, the range of ports it gets will be 49152 to 65535
or ~16384 port numbers:


or 68 connections per second.

The best "fix" is to get your applications to use long-lived TCP
connections. The next best fix after that is to broaden the number of
ports (and perhaps IP addresses) involved. One way to do that is to
have the application attempt to bind() to port numbers in the range of
day 5000 to 65535. That would increase the rate before attempted
TIME_WAIT reuse to


or ~270 connections per second.

You could achieve similar results by spreading the traffic across a
larger number of IP addresses - on the client, the server, or both.

A much more distant fourth option is to decrease the length of TIME_WAIT to
say 60 seconds (math left as an excercise to the reader :)

However, you should "never" take steps to make there be no TIME_WAIT
state at all, such as using an "abortive" close.

> intermittent network startup related errors in running junit nightly test suite
> -------------------------------------------------------------------------------
>                 Key: DERBY-2616
>                 URL: https://issues.apache.org/jira/browse/DERBY-2616
>             Project: Derby
>          Issue Type: Bug
>          Components: Regression Test Failure
>         Environment: m1_ibm15:220>sysinfo
> ------------------ Java Information ------------------
> Java Version:    1.5.0
> Java Vendor:     IBM Corporation
> Java home:       c:\p4\m1\ibm15\jre
> Java classpath:  c:/p4/m1/classes;c:/p4/m1/tools/java/jdbctests.zip;c:/p4/m1/too
> ls/java/jakarta-oro-2.0.8.jar;c:/p4/m1/tools/java/jgl3.1.0.jar;c:/p4/m1/tools/ja
> va/jndi/providerutil.jar;c:/p4/m1/tools/java/jndi/ldap.jar;c:/p4/m1/tools/java/j
> ndi/jndi.jar;c:/p4/m1/tools/java/jnl1.0F.zip;c:/p4/m1/tools/java/junit.jar;c:/p4
> /m1/tools/java/servlet-2_2b.jar;c:/p4/m1/tools/java/xslt4j-2_5_0/xercesImpl.jar;
> c:/p4/m1/tools/java/xslt4j-2_5_0/xml-apis.jar;c:/p4/m1/tools/java/xslt4j-2_5_0/x
> alan.jar
> OS name:         Windows XP
> OS architecture: x86
> OS version:      5.1 build 2600 Service Pack 2
> Java user name:  mikem
> Java user home:  C:\Documents and Settings\Administrator
> Java user dir:   C:\mikem\_tools
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.5
> --------- Derby Information --------
>            Reporter: Mike Matrigali
> I intermitently get network startup related errors in running the nightly full test suite
on my laptop, running XP, with a firewall and a VPN - I am not sure what if any of those environmental
factors is causing it.  I have been mostly ignoring the errors as it seemed like it usually
was only one test.  I my latest run it was more like 7 or 8.  I'll append exact tests as a
comment on this issue.
> To debug the problem I picked one -     org.apache.derbyTesting.functionTests.tests.derbynet.NSSecurityMechanismTest

> and ran it in a loop.  When I did this it failed everytime after the first one (and the
first one  intermittently failed).  When I bumped the  WAIT_TIME  up to 300000  and the SLEEP_TIME
to 500 in
> java/testing/org/apache/derbyTesting/junit/NetworkServerTestSetup.java  then the test
passed everytime .  In 30 runs the
> entire test took  varying times from 2 minutes to 6 minutes, mostly in the 4 minute range.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message