> From: David kerber [mailto:dcker...@verizon.net]
> Now that I've got a thread dump, what am I looking for?
You found it first time :-). Now the hard part - fixing it.
> I've got a
> bunch of sections like this, pretty much all of which are waiting to
> lock <0x057c73e0>. Is there any way to figure out what that
> object is?
> I imagine it's the disk write, but can't figure out how to
> tell for sure.
It's the sync at the start of your method.
> [2009-05-08 10:43:24] [info] waiting for monitor entry
> [2009-05-08 10:43:24] [info] [0x2739f000..0x2739fb64]
> [2009-05-08 10:43:24] [info] at
> eddsrv.EddRcvr.doPost(EddRcvr.java:70)
> [2009-05-08 10:43:24] [info] - waiting to lock <0x057c73e0> (a
> eddsrv.EddRcvr)
... so they're all waiting to get the monitor on a eddsrv.EddRcvr, which is
what the "synchronized" on your doPost method will lock on.
If you say pretty much all are stuck there, then you have massive contention on
that monitor. Time to move to some finer-grained locking! As a first step,
I'd remove the synchronized from the method; I'd replace it with one lock
around the counter updates (locked on one object) and another lock in your
decrypt/log/respond code that's purely around the logging section (locked on a
different object). Then I'd re-evaluate - run, take another thread dump and
see where the bottlenecks are now. If they're anywhere, I'll bet they're
around the logging code.
- Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
