tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <>
Subject Tomcat stops after 'Software caused connection abort' exception
Date Tue, 13 Jun 2000 15:20:22 GMT

Today a customers encountered a dead Tomcat 3.1 on their Solaris server.
Examining the log files showed the cause: Software caused connection abort
	at Method)
	at, Compiled Code)
	at, Compiled Code)
	at, Compiled Code)
Compiled Code)
Compiled Code)
Compiled Code)
	at, Compiled Code)
Endpoint ServerSocket[addr=,port=0,localport=80] shutdown
due to exception: Software caused connection

They couldn't stop Tomcat the normal way, they had to kill the process
manually. The max number of file descriptors is set to 4096. Just before
Tomcat went silent the number of established connection and the ones in
TIME_WAIT were around 40, so everything looked OK.

However for some reason the underlying OS came with the exception:
'Software caused connection abort'. The Berkeley definition is something
like: 'A connection abort was caused internal to your host machine. The
software caused a connection abort because there is no space on the
socket's queue and the socket cannot receive further connections. 

I haven't profiled Tomcat for a long time, but I don't think there is
memory leak with respect to file descriptors not being freed. Therefore
I think the Berkeley description is not applicable over here. Some
people are mentioning this exception can also be raised if setting up
the connection fails, from winsock tutorial: "WinSock description:
Partly the same as Berkeley. The error can occur when the local network
system aborts a connection. This would occur if WinSock aborts an
established connection after data retransmission fails (receiver never
acknowledges data sent on a datastream socket)."

Probably I will never know the reason, however I think Tomcat is a
little brittle in this area. It is very extreme to shutdown your
webserver in case one connection creation fails. I know it is a problem
with Java there are no standardized error codes for all possible
IOException :-( but I think we should check the message and based on
that take appropriate action. In this case I propose to keep the TCP
endpoint running, if the failure rate exceeds a threshold you could
bring him down or do other stuff.

I would like to know what others think about this.

P.S. I don't have time to look into the issue Tomcat couldn't be stopped
decently because the endpoint was down. Is there a reason for this or is
this coincidence?
Mark Brouwer
Virgil B.V.

View raw message