2011/5/4 Mark Thomas <ma...@apache.org>: > 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.
Maybe they can be put into the queue, if there is no data after small timeout? In your scenario they were waiting for 3s. > 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. > >(...) Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
