A good way to debug these types of problems is to tell the JVM to do a Thread stack dump. By reviewing the stack for each processor you can get an idea of what may be causing a problem. On unix you send the JMV a -QUIT signal. On Windows I think you use CTRL-D in the console for Tomcat.
Another thing to check is whether long JVM garbage collection (GC) times are causing requests to stack up. While the JVM is doing GC handling of requests by Tomcat freezes. To get GC data add the arg "-verbose:gc" to your JVM startup options. Regards, Glenn Marinko, Jeff wrote: > Thanks for the reply, Craig. I pretty much figured that was how it worked, > but I was hoping for some kind of time out mechanism. Somehow, someway, I > am able to "lock" up all 200 processors I defined for my Connector in TC > (4.0.4, Java 1.4, Win2K). I'm guessing it is the machine that is at fault > (very low powered), and that since each request potentially opens a > connection to another machine, that may be the cause of the locking. > > Thanks! > > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 27, 2002 4:19 PM > To: Tomcat Users List > Subject: Re: Processor Availability > > > > > On Tue, 27 Aug 2002, Marinko, Jeff wrote: > > >>Date: Tue, 27 Aug 2002 13:45:05 -0700 >>From: "Marinko, Jeff" <[EMAIL PROTECTED]> >>Reply-To: Tomcat Users List <[EMAIL PROTECTED]> >>To: Tomcat Users List <[EMAIL PROTECTED]> >>Subject: Processor Availability >> >>Greetings! >> >>Tomcat uses processors to service requests, as processors free up, they > > then > >>move on and process other requests. > > > Each processor also possesses a thread, so you can think of the set of > available processors as a "thread pool". > > >> My question is this: Is there any way >>to "lock" up all the processors? > > > Sure ... if you send "n+1" simultaneous requests when you've only got "n" > available processors, you're going to run out (assuming that each request > takes enough time for all of them to get submitted before the first ones > start completing. > > Such things happen occasionally when you get spkies of request activity, > but it's usually a transient condition. The analog in plain old web sites > is when a site gets Slashdotted :-). > > >> Is there a maximum time before a processor >>becomes available again, assuming it is taking to long to process a > > request? > > The amount of time your app takes to process a request is totally up to > your app. There's nothing Tomcat can do if you decide to execute a > database query that takes 5 minutes because you're selecting through a > million rows without using an index. > > The time it takes Tomcat to return the processor to the pool when a > request is completed is as small as we can make it (a few milliseconds on > a typical configuration). There's no motivation (or code in Tomcat) for > keeping a processor unavailable any longer than it has to be. > > Besides processors, there might be contention for available threads and/or > TCP/IP socket resources in your operating system. There are also VERY > wide variations in the maximum number of threads a particular OS+JVM > combination can support -- the Volano Report <http://www.volano.com> makes > interesting reading in this regard. > > >>Any way to check how many processors are active/in use? >> > > > There's nothing built in, but it would be straightforward to create a > Valve that was stuck on the Engine (so it could see all requests to all > webapps). Because this Valve will be executed by multiple threads at the > same time, maintaining a simple counter that is incremented at the start > of a request and decremented at the end would give you an active count. > > For the requests being processed by a particular webapp, you could do the > same thing (and portably to boot) using a Filter mapped to "/*". > > >>Jeff >> > > > Craig > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
