: For the jetty based tests, perhaps we should just give a warning if it tries
: to bind a port and can't -- in that case the tests are not called, but we
: still have them for the normal dev case where we can bind the port.
according to the hudson failure logs,the problem hasn't been binding to
the port (as in: the server starting up) it's the client not being able to
onnect to the port in 5ms. (at least: that's hte cause of hte last 6
failures)
given that these tests are running on a virtual server with *lots* of
other virtual servers, it doesn't seem that odd that it might take 5ms
before the connection is initialized
i seem to recall some discussion about increasing that timeout, and
deciding that it was a bad idea because in the "normal" case it's usually
short, but at the very least lets make it a config option or something so
the test can specify a large value. (it doesn't even have to be an easy
to chnge config option, it could even be a system property for now, just
so we can try chaning it in the nightly build environment and see if it
makes things better.
i'd rather not kill a "good" test just because it fails in some situations
-- that tells me that either the test or the code being tested doesn't
handle that situation very well. if the test isn't waiting long enough
for the server to start up before sending requests, then we should fix the
test -- if the client isn't waiting long enough fortheserver to connect,
we should improve the client.
-Hoss
|