Okay that's all starting to make some sense, but it hard to see how
someone would come to this understanding from the documentation.
I also don't see how "|connectionTimeout" will help here in that the
documentation says:
|
The number of milliseconds this *Connector* will wait, after
accepting a connection, for the request URI line to be presented.
The default value is infinite (i.e. no timeout).
If a connection is formed between Apache and Tomcat for 24 requests and
17 are immediately processed due to a maxThreads limit of 18, how would
setting a low "connectionTimeout" help the 17 threads process the other
7 requests?
I'm trying to understand if there is any useful throttling configuration
in which the Java AJP connector has a maxThreads less than Apache's max
AJP connections -- plus 1. Put another way, I'm not quite understanding
any useful "acceptCount" scenario from the "connectionTimeout"
description above.
I know the Java AJP connector uses a thread-per-connection model. I had
assumed that the "maxThreads" meant maximum /active request processing
/threads (e.g. like some old Tomcat releases used to call this
"maxProcessors") and that connections covered by "acceptCount" were
still allocated threads and were still accepted (as the parameter name
implies). I'd further assumed that a fair blocking queue arrangement
would allow "maxThreads" connection threads to run and keep the others
waiting until their turn. I don't see anything in the documentation to
the contrary of this. Further I'm trying to understand any sort of
arrangement with "connectionTimeout" that would give this level of
utility to "acceptCount". As it stands it seems like users can easily
produce devastatingly bad behavior by making assumptions about
"acceptCount" that seem quite logical from the documentation.
Obviously the APR connector can do much better by /not/ allocating
threads to connections beyond "maxThreads". That's great, but juggling
native builds for many different OS's can be a real issue (which is why
I still hold out hope that the NIO connection will come through with
something better than the non-NIO Java connector's performance even if
it is not APR-level performance).
I don't mean to be argumentative -- I'm just really struggling to
understand and hopefully preventing future misunderstandings through
more clarity in the documentation.
--
Jess Holle
Bill Barker wrote:
"Jess Holle" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
There's no intent to handle this case? Really?
Tomcat should throw an "IllegalArgumentException" whenever 'acceptCount'
is set to anything other than 0 explaining this if this is the case!
If so, this is very unfortunate. We use "maxThreads" as a throttle to
limit the concurrency at this level under the (silly?) assumption that
"acceptCount" behaves as documented in the documentation. [Yes, one
could argue that a separate throttle should be used behind this layer,
which we might have been inclined to do if the documentation said
"acceptCount does not work".]
You are misunderstanding how AJP works. Since you don't have a
connectionTimeout on the <Connector />, the connections to httpd stay alive
waiting to get another request on the same socket. As a result, there won't
be any free Threads to handle a new connection so it doesn't matter what
acceptCount is. Their isn't anyone there to accept them.
