"Jess Holle" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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 [EMAIL PROTECTED], 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" <[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. >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
