On 4/7/07, Elias Naur <[EMAIL PROTECTED]> wrote:
No. Compiling and enabling the APR connector instead of the NIO
connector made the problem go away. There were still no ERROR events
sent after the client disconnect (I guess the connection might timeout
sometime later), but the original problem of 100% CPU usage is gone.
I think this is still a problem (or maybe it's normal that you would
only get a timeout later, but I doubt it ...).
Maybe you can see what are the status codes which are reported by the
poller by adding some logging: the class is
org.apache.tomcat.util.net.AprEndpoint.Poller (the add method adds the
sockets to the poller, and the poll method is called in the run
method). Normally, you're supposed to be in that case because APR
would report either POLLHUP or POLLERR (but this is assuming this is
detected by the os, and the status codes are right):
// Check for failed sockets and hand this
socket off to a worker
if (((desc[n*2] & Poll.APR_POLLHUP) ==
Poll.APR_POLLHUP)
|| ((desc[n*2] & Poll.APR_POLLERR)
== Poll.APR_POLLERR)
|| (comet &&
(!processSocket(desc[n*2+1], SocketStatus.OPEN)))
|| (!comet &&
(!processSocket(desc[n*2+1])))) {
// Close socket and clear pool
if (comet) {
Here>>>>>>>>>> processSocket(desc[n*2+1], SocketStatus.DISCONNECT);
} else {
Socket.destroy(desc[n*2+1]);
}
continue;
}
Rémy
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
