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
