tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <je...@ptc.com>
Subject Re: Serious non-native AJP connector issue
Date Fri, 15 Jun 2007 02:40:01 GMT
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" <jessh@ptc.com> wrote in message 
> news:4671E278.8020204@ptc.com...
>   
>> 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.
>   


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message