> -----Original Message----- > From: Jeff Kilbride [mailto:[EMAIL PROTECTED]] > 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" <[EMAIL PROTECTED]> > To: "Tomcat Users List" <[EMAIL PROTECTED]> > 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: <mailto:[EMAIL PROTECTED]> > For additional commands: <mailto:[EMAIL PROTECTED]> > Troubles with the list: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
