RE: Common Problem with Tomcat/Apache (processer sticks at 97% on linux)

[Randy Layman <ra...@aswethink.com>]

> -----Original Message-----
> From: Jeff Kilbride [mailto:jeff@kilbride.com]
> Sent: Friday, November 16, 2001 6:43 PM
> To: Tomcat Users List
> Subject: Re: Common Problem with Tomcat/Apache (processer 
> sticks at 97%
> on linux)
> 
> 
> ----- Original Message -----
> From: "Brandon Cruz" <bc...@norvax.com>
> To: "Tomcat Users List" <to...@jakarta.apache.org>
> Sent: Friday, November 16, 2001 7:01 AM
> Subject: RE: Common Problem with Tomcat/Apache (processer 
> sticks at 97% on
> linux)
> 
> 
> > Thank you for the suggestions, so to upgrade to a newer 
> version of tomcat
> > 3.2.x, all I have to do is switch jar files in 
> tomcat_home/lib?  Do you
> > think that may help with the 97% processor problem?
> 
> That's what the Readme file that comes with the distribution 
> says -- and it
> worked for me. I remember 3.2.1 (and possibly 3.2.2) having a 
> known runaway
> processor problem, but I don't remember what caused it. 
> Something to do with
> mapping a servlet incorrectly could cause a runaway, I think. 
> I believe it
> was fixed by 3.2.3. As I said, I think 3.2.4 is going to be 
> released very
> soon, so you might wait for that distro.

The problem was setting up your contexts so that nothing was registered to
handle the root context.  Then out of context 404 errors caused an endless
loop.  This should have been seen on all platforms and probably not the
cuase of the problem here.

> 
> > As far as garbage collection, this condition stays this 
> way, even after 12
> > hours.  Would that be an indication of garbage collection 
> or an endless
> loop
> > somewhere?  If it is in our developers code, then I would 
> expect this to
> > reproduce on any machine, development on win2k, or production on
> > linux-apache-tomcat.  Still can only find this on the linux-apache
> machine.
> >
To me this sounds like a threading issue - its not always reproducable,
doesn't seem to be consistent, etc.  I would suggest you have your
developers look into where they are using threads and synchronized code.  If
possible I would suggest you use something like OptimizeIt! - these tools
work well at find memory leaks and sometimes deadlock.

	Randy

> 
> > Thanks Again!
> >
> > Brandon
> 
> --jeff
> 
> 
> --
> To unsubscribe:   <ma...@jakarta.apache.org>
> For additional commands: <ma...@jakarta.apache.org>
> Troubles with the list: <ma...@jakarta.apache.org>
> 

--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>