Simon, On 10/29/15 4:28 AM, simone.rodenbach....@devk.de wrote: > Thx, > > I hope this information helps: (The > org.apache.commons.pool.impl.GenericObjectPool starts a timer ... ) > > ava.util.TimerThread @ 0xc0772288 > |Timer-0| 128 | 384 > |org.apache.catalina.loader.WebappClassLoader @ 0xc04bed30|true > |- at java.lang.Object.wait(J)V (Native Method) > | | | | > | > |- at java.util.TimerThread.mainLoop()V (Timer.java:552) > | | | | > | > |- at java.util.TimerThread.run()V (Timer.java:505) > | | | | > | > | '- <local> java.util.TimerThread @ 0xc0772288 Timer-0 Thread > | | 128 | 384 | > | > | |- <class> class java.util.TimerThread @ 0xc0cd5080 System Class > | | 0 | 0 | > | > | |- group java.lang.ThreadGroup @ 0xc048b400 main > | | 48 | 208 | > | > | |- contextClassLoader org.apache.catalina.loader.WebappClassLoader @ > 0xc04bed30 | | 200 | 1.314.384 | > | > | |- <Java Local>, queue java.util.TaskQueue @ 0xc0758a80 Busy Monitor > | | 24 | 1.528 | > | > | |- <Java Local> java.util.TimerThread @ 0xc0772288 Timer-0 Thread > | | 128 | 384 | > | > | |- name char[7] @ 0xc0772408 Timer-0 > | | 32 | 32 | > | > | |- inheritedAccessControlContext java.security.AccessControlContext @ > 0xc0772428 | | 40 | 104 | > | > | |- inheritableThreadLocals java.lang.ThreadLocal$ThreadLocalMap @ > 0xc0772490 | | 24 | 104 | > | > | |- blockerLock java.lang.Object @ 0xc07724f8 > | | 16 | 16 | > | > | |- <Java Local> org.apache.commons.pool.impl.GenericObjectPool$Evictor > @ 0xeefe76d0| | 40 | 40 | > | > | |- <Java Local> java.lang.Object @ 0xeefe76f8 > | | 16 | 16 | > | > | '- Total: 11 entries > | | | | > | > '- Total: 3 entries > | | | | > | > --------------------------------------------------------------------------------------------------------------------------------------------
This was very difficult to interpret. > The stacktrace shows only: > > Timer-1 > at java.lang.Object.wait(J)V (Native Method) > at java.util.TimerThread.mainLoop()V (Timer.java:552) > at java.util.TimerThread.run()V (Timer.java:505) This was not, and it was about what I expected. Usually when a thread if blocked on a monitor, it will give you the hex address of the object being used as the monitor, and then you can do find out what object that is. In the case of the Timer, it might just be it's waiting on itself. Once you find out what that timer does when it wakes up, you'll probably find out who created the timer. If the timer thread truly is executing the GenericObjectEvictor, then there may be a bug in Tomcat. I don't see anything in the changelog that would explain this, but could you re-try your testing with Tomcat 6.0.44? -chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
