tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Richard <charle...@thelearningbar.com>
Subject Re: Tomcat thread dump analysis
Date Wed, 08 May 2013 12:21:30 GMT
Oh and sorry, we are using Tomcat 6.0.30 .

Cheers!


On Wed, May 8, 2013 at 9:20 AM, Charles Richard <
charles.r@thelearningbar.com> wrote:

> Hi,
>
> We have a weird issue on our site which some random trigger event will
> backup all c3p0 connections until it hits the max pool size.
>
> I have scripts that will do a softReset on the c3p0 connection pool when
> they hit their max so help us manage the issue and to also help me have
> time to hopefully get some decent thread dumps to catch the underlying
> issue.
>
> The problem happened yesterday and I get a lot of these:
>
> "TP-Processor396" daemon prio=10 tid=0x00002aff2ba9d000 nid=0x5a7b waiting
> on condition [0x00002aff61e98000]
>    java.lang.Thread.State: WAITING (parking)
>         at sun.misc.Unsafe.park(Native Method)
>         - parking to wait for  <0x00002afecfb91da0> (a
> java.util.concurrent.Semaphore$NonfairSync)
>         at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
>         at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:811)
>         at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:969)
>         at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
>         at java.util.concurrent.Semaphore.acquire(Semaphore.java:286)
>         at
> com.tc.object.locks.LockStateNode$PendingLockHold.park(LockStateNode.java:179)
>         at
> com.tc.object.locks.ClientLockImpl.acquireQueued(ClientLockImpl.java:723)
>         at
> com.tc.object.locks.ClientLockImpl.acquireQueued(ClientLockImpl.java:701)
>         at com.tc.object.locks.ClientLockImpl.lock(ClientLockImpl.java:52)
>         at
> com.tc.object.locks.ClientLockManagerImpl.lock(ClientLockManagerImpl.java:98)
>         at com.tc.object.bytecode.ManagerImpl.lock(ManagerImpl.java:747)
>
> If I look at a stack before the issue happened, I see no TP-Processor
> threads with the "parking to wait for". What can i read into this?
>
> Thanks,
> Charles
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message