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:31:12 GMT
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