As I mentioned you can get a thread dump by issuing a kill -SIGQUIT to the java 
process. Its probably not that pretty and I don't know of any tools to make it more 
readable but i'm sure there are some.

Jvmstat is a free tool provided by sun which hooks into your jvm and gives a graph of 
the time that your jvm spends during garbage collection. The standard collectors stop 
the whole jvm during the collection so obviously you want it to spend as little time 
as possible in this phase. I've put a couple of links for some articles i've found 
useful in the past below.

http://java.sun.com/docs/hotspot/gc1.4.2/
http://java.sun.com/developer/technicalArticles/Programming/turbo/
http://java.sun.com/developer/technicalArticles/Programming/GCPortal/ReadMe_Solaris.html

Good luck
Matt

-----Original Message-----
From: Michael Medwith [mailto:[EMAIL PROTECTED]
Sent: 20 September 2004 16:22
To: Tomcat Users List
Subject: Re: Connections backup for modjk, all w's


Thanks for the input we are in the process of getting a Profiler
purchased but the time to get it into production will be a couple of
months unless we can speed up the paperwork.  As for garbage
collection I will look into that is there a happy medium for memory
usage... these boxes are huge with lots of memory (several GB) and
multi processors per box


Someone at work recently thought it could be garbage collection
kicking in as well... is there something I can do before the profilers
are installed, maybe a core dump?

-Mike


On Mon, 20 Sep 2004 16:01:32 +0100, Dale, Matt <[EMAIL PROTECTED]> wrote:
> 
> Then personally the things i'd look at would be a thread dump of tomcat to find out 
> if some of the requests are hung, look for bad loops or bits of code that might wait 
> and therefore not freeing up the response. A profiler may help here but you'd have 
> to profile the live app if you are unable to replicate this outside your live 
> environment.
> 
> Perhaps the app is using more memory than is required and spending too much time in 
> garbage collection causing the connections to back up. You can monitor this in a 
> profiler and a more visual representation with jvmstat from sun.
> 
> Apache logs and catalina.out are often full of useful error messages but it doesnt 
> sound like you have a specific error here.
> 
> 
> 
> -----Original Message-----
> From: Michael Medwith [mailto:[EMAIL PROTECTED]
> Sent: 20 September 2004 15:52
> To: Tomcat Users List
> Subject: Re: Connections backup for modjk, all w's
> 
> Our company uses covalent for support, I am a mere developer.  I don't
> even have control or major influence of the platforms or
> administration.  I will mention that right away...
> 
> To be honest, I have a feeling its something code/network related
> because it was happening prior to apache 2.0...
> 
> Any more suggestions would be much appreciated, is there anything I
> can research or look for in code or logs or status pages?
> 
> -Mike
> 
> On Mon, 20 Sep 2004 15:44:36 +0100, Dale, Matt <[EMAIL PROTECTED]> wrote:
> >
> > Out of interest is there any reason why you aren't using JK2? Have you tried it? 
> > This was designed for Apache 2 so may work better. I'm sure this isn't relevant 
> > but it might be worth a shot.
> >
> > Ta
> > Matt
> >
> >
> >
> > -----Original Message-----
> > From: Michael Medwith [mailto:[EMAIL PROTECTED]
> > Sent: 20 September 2004 15:42
> > To: Tomcat Users List
> > Subject: Re: Connections backup for modjk, all w's
> >
> > apache 2.050
> > tomcat 4.1.27
> > mod jk, 1.41_05, sometimes _06
> >
> > -Mike
> >
> > On Mon, 20 Sep 2004 15:21:04 +0100, Dale, Matt <[EMAIL PROTECTED]> wrote:
> > >
> > > What versions of the 3 components are you using?
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Michael Medwith [mailto:[EMAIL PROTECTED]
> > > Sent: 20 September 2004 15:11
> > > To: [EMAIL PROTECTED]
> > > Subject: Connections backup for modjk, all w's
> > >
> > > I am really lost on this one, my application at work (running with
> > > apache/tomcat/modjk) is locking up with all "W"s.  We have 5 new
> > > solaris machines running tomcat and 5 more with apache (1 to 1
> > > relationship).
> > >
> > > The application seems to lock up on a regular basis.  The most useful
> > > information to this point is our apache server-status which shows
> > > hundreds of "W"'s  implying that we are writing responses back to
> > > users.  The fact is none of these responses are supposed to be long
> > > writes.
> > >
> > > Has anyone ever filled up their apache queue with all "W"s?  What are
> > > somethings to look into on this.
> > >
> > > Some things that we have looked into that have resulted in no leads:
> > >
> > > Connections to all databases are low in any,
> > > No apparent network clogs on internal network,
> > > Unable to reproduce under software load testing,
> > >
> > > Anyone with any suggestions or more questions would be much
> > > appreciated, we have been dealing with this for quite some time now
> > > with no hope of a remedy in the near future.
> > >
> > > -Mike Medwith
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > >
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Any opinions expressed in this E-mail may be those of the individual and not 
necessarily the company. This E-mail and any files transmitted with it are 
confidential and solely for the use of the intended recipient. If you are not the 
intended recipient or the person responsible for delivering to the intended recipient, 
be advised that you have received this E-mail in error and that any use or copying is 
strictly prohibited. If you have received this E-mail in error please notify the 
beCogent postmaster at [EMAIL PROTECTED]
Unless expressly stated, opinions in this email are those of the individual sender and 
not beCogent Ltd. You must take full responsibility for virus checking this email and 
any attachments.
Please note that the content of this email or any of its attachments may contain data 
that falls within the scope of the Data Protection Acts and that you must ensure that 
any handling or processing of such data by you is fully compliant with the terms and 
provisions of the Data Protection Act 1984 and 1998.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to