threads were waiting on. If there were more than one, I will start with the lock on which the most threads are waiting on. Using the thread id, I would trace the life span of the thread
holding the lock in the rest of the thread dumps to see how long it was holding the lock.
If the same thread held the lock through out, there may be some external factor slowing it down. In this case it is doing file I/O so I would for things like file system running out of space or the file size getting too big.
Since your problem may be related to log archiving, can you disable that feature to see if it makes any different. Very often I found that a complete different bottleneck may surface when you remove one that is the most obvious. Hopefully that is not your case.
Bill
On 10/14/06, sksamuel <[EMAIL PROTECTED]> wrote:
>A thread dump is a snap shot of the JVM at a particular moment in time.
> I find it useful to take consective thread dumps about 5 seconds apart.
> That gives a moving picture of the JVM. You may want to vary the number
> of dumps or the time apart.
>
> The thing to look for is how long are the threads waiting for a lock.
> Lots of time I found things to be transient. (ie the first dump showing
> many
> threads waiting for lock(s) but in the dump 5 seconds later they are
> done).
>
> You can use the thread id to following what is happening to a thread over
> multiple thread dumps.
Thanks for the reply Bill. I've done what you suggested and now have thread
dumps spanning a minute. There are many threads still sat in the waiting for
monitor stage, any advice on where I go next to try and figure out what the
deadlock is ?
_______________________________________________
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
_______________________________________________ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
