On May 8, 2013, at 8:39 AM, Charles Richard wrote: > 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:
If this is the problem that you're experiencing it does not seem to be related to Tomcat. You might be better off posting on the Terracotta or Spring forum, depending on the exact problem. Dan > > 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 >>> >>> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
