Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=sbcglobal.net;
  h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
  b=eLiTZgp1O90PhzEtwVZWdBeVBH0czniUY85uwP3L+Jcugo/dr8CE5fwen8tVXz7dVet4dQX9Mku4B/OTxR2PhbgPEocgrdRz5oDRsn5dSQNCf6eFCi1cNtaONl/qz4S6a3nk7TNUI51pXJ8cVq54FRu/DqXJYv6QLBtzHr839ko=
  ;
Message-ID: <47D1F11C.90807@sbcglobal.net>
Date: Fri, 07 Mar 2008 17:51:24 -0800
From: Mike Matrigali <mikem_app@sbcglobal.net>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: [jira] Commented: (DERBY-3514) SecureServerTest failing with
 timeout waiting for the network server to start only when run in
 derbynet._Suite
References: <1846044026.1204926706349.JavaMail.jira@brutus>
In-Reply-To: <1846044026.1204926706349.JavaMail.jira@brutus>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Daniel John Debrunner (JIRA) wrote:
>     [ https://issues.apache.org/jira/browse/DERBY-3514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576389#action_12576389 ] 
> 
> Daniel John Debrunner commented on DERBY-3514:
> ----------------------------------------------
> 
> Issue was due to an earlier test calling a network server command that failed (setting trace on with an invalid directory).
> For most of the network server commands if an exception is thrown the network socket is never closed (left to garbage collection).
> Most likely the longer wait that NetworkServerTestSetup had was enough time to get the socket closed and thus freed up for the network server to use.
> 
> I accidentally committed a reduced wait time in NetworkServerTestSetup yesterday while working on DERBY-3504.
> I plan on leaving this reduced time (10 seconds to start the server rather than the old 300 seconds)  as the server should come up in that time and my belief is that extending the time is really just hiding bugs (like this one).
> 
Is 10 seconds really the number across all platforms, accounting for any
other activity that may be happening on the machine?  It would be nice 
if our tests didn't fail mysteriously with a timeout error if some other
activity on the machine happened to affect performance.

It would be great if someone could fix all the tests to properly 
cleanup, but for now pouring through intermittent timeout diffs is
not helping me tell if my latest change broke the codeline or not.
The reality is that now I will run less tests, ignoring the failures
in those tests that timeout.  With the timeout set high at least the
tests run and the functionality is tested.  I agree there may be a 
missed bug in a test or even more serious if network startup started
to take 5 minutes everytime.

Do you have any hints on how to find the previous test that may be
causing the bug if I am hitting timeouts for this reason?

If we think performance of network startup is an issue worth testing 
then we should just add a performance test for that.  I am not sure what
such a test would consider passing for all platform/cpu's that 
developers might be running regression tests on (including their 
handheld devices).  For a pass/fail unit test it might be interesting to
run some accepted performance test and then define a stake in the ground
that performance of test X should be no longer than Y * the benchmark on 
that platform.
>> SecureServerTest failing with timeout waiting for the network server to start only when run in derbynet._Suite
>> --------------------------------------------------------------------------------------------------------------
>>
>>                 Key: DERBY-3514
>>                 URL: https://issues.apache.org/jira/browse/DERBY-3514
>>             Project: Derby
>>          Issue Type: Bug
>>          Components: Network Server, Regression Test Failure
>>    Affects Versions: 10.4.0.0
>>         Environment: IBM 1.5 windows
>>            Reporter: Daniel John Debrunner
>>            Priority: Minor
>>
>> Running the test by itself shows no problems.
>> From some debugging it seems the spawned network server (separate jvm) is coming up correctly and listening on the right address, however the pings to see if it started are never seen by the ClientThread. I checked the timing and they do overlap.
>> The server address is the wildcard address 0.0.0.0.
>> If a server is listening to localhost:1527 then another server fails to start if it is listening to 0.0.0.0:1527, I wondered if it would start on the real address and just wait for the loopback to become free.
>