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.
