On 04/05/2011 12:04, Konstantin Kolinko wrote: > I do not quite get what happens in 6s. My first understanding from > reading the scenario was that the threads at 2s are busy because we > need them to process keep-alive connections. Then I see that at 6s > keep-alive connections are in the Queue. > > What prevents those connections that exist at "2s" from being placed > in the Queue?
The keep-alive state is as viewed by the client. At 6s the requests in the queue are open connections that have already processed one requests and therefore are in HTTP keep-alive. However, there are no free threads to process them. If any data was to turn up on those connections they would sit in the queue until a thread was available. The difference between "Allocated threads. In HTTP keep-alive Xs" and "Queued. In HTTP keep-alive for Xs" is that in the allocated case, data will be processed as soon as it arrives. In the queued case, data will not be processed a) all the connections ahead of it in the queue have been processed and b) a thread is available to process it. > What is "simulated polling" that you tried to implement? Was it trying > to read data from each of keep-alive sockets in turn with a short > timeout? Exactly. > Where increased CPU usage comes from? Because of the short timeout, threads that would normally be blocked are generating SocketTimeoutExceptions and looping through the Http11Processor.process method every 100ms. >> The proposed changes are: >> a) restore disabling keep-alive when threads used >= 75% of maxThreads > > Anyway, if the problem persists, I'll be +1 for a), as it should > prevent us from falling in this state. That certainly would deal with the immediate issue. I didn't fully understand Filip's changes when I removed the code that disabled keep-alive. > +0 for b)..e), as I do not quite get them. An alternative could be to > change the default value of maxConnections and calculate it from > maxThreads. With the change described in a), maxConnections is effectively an duplication of acceptCount for BIO. Changes c) and d) are intended to remove the duplication so acceptCount functions as it does in Tomcat 6. maxConnections duplicates pollerSize for APR. Change b) is intended to remove the duplication. Change e) will align the docs with whatever changes are made. Currently maxConnections is documented as only applying to BIO whereas it applies to BIO, NIO and APR. > I wonder, maybe it is time to use the NIO connector as the default one > in Tomcat 7. I was beginning to think the along the same lines although I was actually thinking remove BIO entirely for Tomcat 8. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
