Robert Schuster wrote:
Hi,
I still have trouble with the Sockets ....
First I found out that certain Sockets which do not succeed in establishing a
connection (a wanted scenario in the mauve test) do not get properly closed. I
took some time until I found the simple answer: These sockets do their connect()
attempt inside the constructor. When connect() throws an exception the caller
will not get an instance on which it can call close(). I therefore added some
exception handling code and thought: "Yeah, now those spurious BindExceptions in
every quick second test run will be fixed."
However this is not the case. :(
A little googling about 'unbinding' a socket revealed that this is achieved by
closing it (fine I thought). However it also tells that a closed socket remains
busy for 60 seconds on most systems. Ok this looks exactly like the problem I
faced.
But WTF? Running the tests quickly after on the RI does not cause those
BindExceptions? What is this? Magic?
I felt lost and so put out strace to see what the RI is doing with my operating
system. I saw no special system calls and to my surprise not a single failing
bind() call.
Do they set SO_REUSEADDR? on the listening socket? That is the only way
I know of to be able to bind to the same address before the timeout expires.
Also if there is a clean shutdown of any TCP connections that took place
on the socket that would help the situation. Are you calling shutdown()
before closing?
Why not have the test open a different socket each time by binding to
the wildcard address and allowing the OS to choose the port? This is
what I did in gnu.testlet.java.net.HttpURLConnection.TestHttpServer.
David Daney
