You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jim Rudnicki <jd...@pacbell.net> on 2000/01/01 01:16:14 UTC
commented out setSoTimeout() in EndpointManager
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....
Happy New Year,
Jim
Re: commented out setSoTimeout() in EndpointManager
Posted by Brad Cox <bc...@virtualschool.edu>.
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, Costin.Manolache@eng.sun.com 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.
>
>Costin
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
---
Dr. Brad Cox bcox@virtualschool.edu
Phone: 703 361 4751 Fax: 703 995 0422 Cellular: 703 919-9623
http://virtualschool.edu A Project with Paradoxical Goals
PGP Signature: E194 C6E5 92D8 B8FB 20E8 8667 929A 95A0 FCB6 7C62
Re: commented out setSoTimeout() in EndpointManager
Posted by Co...@eng.sun.com.
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.
Costin