Bill Barker wrote:
I don't remember anything like that for 3.3.x (and nothing even close is(forwarding to tomcat-dev)
open in BZ). But, then again, I don't imagine that very many people try and
use the Http10Connector in production, and Coyote is only available in the
nightly for 3.3 until 3.3.2 comes out.
o.a.t.u.net.PoolTcpEndpoint won't close the ServerSocket itself without
shutting down. It looks like the root cause is from the JVM, nio, O/S, or
some other place we can't see.
Ok, I looked at it more, and the TCP endpoint code considers an exception during accept a normal event:
From PoolTcpEndpoint:
try {
if (running) {
....
accepted = factory.acceptSocket(serverSocket);
....
catch (SocketException e) {
// TCP stacks can throw SocketExceptions when the client
// disconnects. We don't want this to shut down the
// endpoint, so ignore it. Is there a more robust
// solution? Should we compare the message string to
// "Connection reset by peer"?
// socket exceptions just after closing endpoint (when
// running=false) aren't even logged
if (running != false) {
String msg = sm.getString("endpoint.err.nonfatal",
serverSocket, e);
log(msg, e, Log.INFORMATION);
}
}
OTOH, I don't think this should be the case, and I think we should stop/start the server socket in that particular case, as was done in the old HTTP connector:
try {
socket = serverSocket.accept();
....
} catch (IOException e) {
try {
// If reopening fails, exit
synchronized (threadSync) {
if (started && !stopped)
log("accept error: ", e);
if (!stopped) {
serverSocket.close();
serverSocket = open();
}
}
....
The root of the problem could be a defiency in the JVM's network code, but IMO this shouldn't kill the connector.
Remy
--
To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
