tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: Serious non-native AJP connector issue
Date Fri, 15 Jun 2007 03:41:48 GMT

"Jess Holle" <jessh@ptc.com> wrote in message news:4671FC01.60408@ptc.com...
> 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).
>

In practice, this is a timeout on a wait on a keep-alive connection (since 
request-body processing usually happens fast).  If this particular 
connection in the pool isn't reused in the time allowed, then Tomcat will 
close it and put the thread back in the queue to process new connections. 
Using CPing/CPong is recommended in this case to allow httpd to understand 
that Tomcat has hung up the phone.  So, if after the first request, httpd 
chooses to not reuse this connection for a long time, then the thread can 
recycle itself.

> 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?
>

It would cause the TC threads listening for a new request to believe that it 
will never come, and they will throw themselves back into the pool.

> 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.
>

Using acceptCount is normally useless.  The case where it is is when you 
suddenly get a very very large number of hits to your app faster than Tomcat 
can handle.

> 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.
>

The acceptCount is only useful to handle unexpected floods of requests. 
Using the connectionTimeout means that the Tomcat thread won't just sit and 
listen forever for that particler socket connection to send another request, 
and will be freed up to be re-assigned to another socket connection.  With 
any reasonable setting, the connectionTimeout is just how long Tomcat will 
maintain a keep-alive with httpd (which is very different from how long 
httpd will keep a keep-alive with the client).

> 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).
>

It seems that we lost building the NIO/AJP connector in Tomcat, but since i 
recognize you from dev@httpd, you will have seen that already :).  Last time 
I tested, the experimental NIO/AJP connector performed better than either 
the default or the APR connector on Solaris (surprise, surprise), and came 
in dead last on Windows.

> 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.
>

With the documentation, as with the code, patches are always welcome :).


> --
> 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.
>>
>
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message