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:39:28 GMT
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 <
charles.r@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 <dmikusa@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>

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