Sending a QUIT signal works in Unix (Linux and Solaris), but Ctrl-D doesn't do anything in Windows 2000. Anybody knows something about it?
Jeff, what kind of processing are you doing in your JSP/servlets? You could be experiencing deadlock problems. It's just an idea :-) Best regards, Rodrigo Ruiz ----- Original Message ----- From: "Glenn Nielsen" <[EMAIL PROTECTED]> To: "Tomcat Users List" <[EMAIL PROTECTED]> Sent: Thursday, August 29, 2002 2:20 AM Subject: Re: Processor Availability > 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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
