If you're talking about the non-native AJP connector, then this is a
long-standing issue.
acceptCount is essentially ignored in this case and all concurrent
requests above pool size /minus 2/ go off into limbo and are not handled
properly. I don't understand the off-by-2 error, but it is clearly there.
If you're talking about some other connector, then I cannot speak to
that -- as I use the pure Java (non-NIO for stability) connector.
Native connectors are just too painful to build, update, and
troubleshoot across all the platforms I deal with. This clearly isn't
going to change no matter how stable these connectors are and I need to
use Apache anyway, so native connectors are a dead end. It's either
old-IO or NIO, but it needs to be pure Java for me.
--
Jess Holle
On 5/10/2010 7:35 AM, André Warnier wrote:
Timir Hazarika wrote:
Andre,
Response from Leon just about summarizes this issue: the shock
absorber you
mention is not configurable. Setting the acceptCount to 1 or nine
hundred
produces exactly the same behavior in terms of connections awaiting
response.
Then that would be a bug, no ? In the sense that the documentation says :
acceptCount
The maximum queue length for incoming connection requests when all
possible request processing threads are in use. Any requests received
when the queue is full will be refused. The default value is 100.
http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
The "stricter" scheme hence, serves as a usable application
workaround for
now.
If the above bug is real, then yes, it makes a difference.
I still believe that handling this at the level of a front-end makes
more sense. At least there, you can return something nice rather than
brutally rejecting the connection, and you can also examine the
request to determine if you really want to block it or not.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
