tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Brad Cox)
Subject Re: commented out setSoTimeout() in EndpointManager
Date Wed, 05 Jan 2000 19:00:49 GMT
I'm reasonably confident that aServerSocket.accept() has a bug, based on experience to date
debugging a similar server within Redhat Blackdown and IBM (Visual Age) VMs. 

The root problem is that aServerSocket.close() should, but does not, interrupt the accept().
The debugger shows that its thread is still blocking inside the accept() call even once the
serversocket is closed by a different thread. This causes all subsequent restarts to fail
with a "port busy" message. Most will not see this in tomcat because it stops by killing its
VM, but it  definitely bites if you restart the server within the original VM.

I suspect this is the real reason the the setSoTimeout was introduced in the first place.
I added a setSoTimeout to my application and it fixed my port busy problems.

I've never seen this reported or discussed elsewhere, so I might well be wrong. Please let
me know if so!

	Brad Cox

At 6:28 PM +0000 01/05/2000, wrote:
>Jim Rudnicki wrote:
>> In class EndpointManager, method addEndpoint() at line 242 is:
>>    // ss.setSoTimeout(timeout);
>> For some reason, the timeout has been removed.
>> Without the timeout enabled on the ServerSocket, the Endpoints are not
>> shutting down.  Instead the Endpoints are blocked indefinitely  at line 114
>>   Socket socket = serverSocket.accept();
>> The Endpoints are written to deal with the timeouts by catching
>> InterruptedIOException and continuing on.
>> The effect of this is that the server does not stop() fully.  The Endpoints
>> never inform the manager thru notifyEndpointDown().  Most important, the
>> socket stays connected because the Endpoint thread is blocked forever.  In
>> the standalone application, the sockets get torn down when the application
>> exits, so all appears well.
>> I detected this problem when using the HttpServer embedded in another
>> application.  The server start()'s and runs, and appears to stop().  But, if
>> in the same application instance you try to start() a new instance of the
>> HttpServer, it fails indicating that the port is in use.  Indeed, the port
>> is in use because the old Threads are still running and holding onto the
>> Socket objects.
>> The commented out line is present In the 3.0 release source code and is
>> still present in the snapshot code dated Dec 31,1999.  It would be tempting
>> to just remove the comment, but then again, somebody marked it out for a
>> reason....
>The reason: kaffe doesn't implement it ( and crashes if it is present ).
>Probably kaffe is not so important, but it is the default VM on RedHat
>and it was the only change needed to support it.
>I don't mind adding the line back, but I'm not sure it's the real problem
>in this case - stop() should be able to interupt the listen thread.
>To unsubscribe, e-mail:
>For additional commands, e-mail:

Dr. Brad Cox
Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623 A Project with Paradoxical Goals
PGP Signature: E194 C6E5 92D8 B8FB 20E8  8667 929A 95A0 FCB6 7C62

View raw message