tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rodrigo Ruiz" <rr...@gridsystems.com>
Subject Re: Processor Availability
Date Fri, 30 Aug 2002 12:20:40 GMT
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" <glenn@mail.more.net>
To: "Tomcat Users List" <tomcat-user@jakarta.apache.org>
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:craigmcc@apache.org]
> > 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" <Jeff_Marinko@intuit.com>
> >>Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> >>To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> >>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:tomcat-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> > <mailto:tomcat-user-help@jakarta.apache.org>
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
<mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
<mailto:tomcat-user-help@jakarta.apache.org>
>
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:tomcat-user-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message