On 10/29/15 7:14 AM, Christopher Schultz wrote: > 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?
If it is a problem related to the Evictor, it is likely in commons pool. As Chris pointed out, the config specified the commons dbcp datasource directly, rather than using the tomcat-provided repackaged jar. It would be good to know what versions of Commons Pool and DBCP you have in the classpath. If you remove the DS override and upgrade to 6.0.44 you will pick up the latest compatible versions. If for some reason you want to keep the override, you should check the versions and make sure that Pool is 1.5.7 (or 1.6) and DBCP is 1.4. Phil > > -chris > > --------------------------------------------------------------------- > 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
