https://issues.apache.org/bugzilla/show_bug.cgi?id=54036
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #12 from Mark Thomas <ma...@apache.org> ---
The thread dump shows that you have a large number of new connections that are
not sending any data. Hence, since BIO and APR/native both block during the
reading of the request line, the threads will remain blocked until the read
times out of the client sends more data.
You can see this by examining the stack trace. For example:
"http-apr-80-exec-96" - Thread t@137
java.lang.Thread.State: RUNNABLE
at org.apache.tomcat.jni.Socket.recvbb(Native Method)
at
org.apache.coyote.http11.InternalAprInputBuffer.fill(InternalAprInputBuffer.java:575)
at
org.apache.coyote.http11.InternalAprInputBuffer.parseRequestLine(InternalAprInputBuffer.java:134)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:927)
process(AbstractHttp11Processor.java:927)
This is when the processor triggers the read of the request line. The parameter
it passes in (keptAlive) indicates is this is the first request received on the
connection (keptAlive will be false) or a subsequent request (keptAlive will be
true). It is important for this issue to know if keptAlive is true or false.
parseRequestLine(InternalAprInputBuffer.java:134)
This is the reading data from the socket for the request line and parsing it.
Since we are at line 134 we know useAvailableData == false (else the if block
starting on line 131 would have been executed and the method would have
returned false to the caller. If useAvailableData == false then keptAlive ==
false. This tells us that this is the first request on the connection.
fill(InternalAprInputBuffer.java:575)
This is the InputBuffer attempting to read enough (actually any) data into the
buffer so it can be parsed as a request line. It is blocking as there is no
data to read.
Putting everything together we know that:
- this thread is processing a new connection from a client
- the connection has been established but no data has been sent
- Tomcat is waiting for data to arrive so it can parse the request line
If you have lots of clients doing this then you have some broken clients.
Switching to the NIO connector may help since it is non-blocking while reading
the request line and request headers (all connectors block while reading
request bodies).
I have no idea what it is between your CentOS 5 and CentOS 6 installations that
is triggering this issue. It may be related to defer accept but still, the
clients are misbehaving.
There is no Tomcat bug here. If you need further assistance, the Tomcat users
mailing list is the place to seek help.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
