Just saw this which I believe describes exactly what is happening: http://forums.terracotta.org/forums/posts/list/6470.page
We are using Spring as well. Trying to understand the solution: Charles On Wed, May 8, 2013 at 9:31 AM, Charles Richard < charle...@thelearningbar.com> wrote: > We are using Terracotta which is a bit of a black box to me (setup I've > inherited). Terracotta helps us with the Tomcat sessions being > "transportable" across front end servers. > > Cheers! > Charles > > > On Wed, May 8, 2013 at 9:27 AM, Daniel Mikusa <dmik...@gopivotal.com>wrote: > >> >> On May 8, 2013, at 8:20 AM, Charles Richard 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) >> >> What in your application is using the "com.tc.object.locks" package? >> This is not used by Tomcat. >> >> Dan >> >> >> > >> > 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 >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >