connection pool stop needs to be called before the static shutdown methods. Because stop is called via a destroy-method, you must only call the static shutdowns from your shutdown bean, and only after the connection pool has stopped. So there should be a depends-on relation between the beans (shutdown depends on pool). I think they will be stopped in reverse order.
Every call to close results in a call to stop on the inactivity monitor which tracks the inactivity monitor executor and calls shutdown when the reference count drops. Looking at it now, it may be that it needs to call java.util.concurrent.ThreadPoolExecutor#shutdownNow for that case where some tasks are executing. On 20 July 2012 03:41, liny <[email protected]> wrote: > Thanks, Gary. > > I created a bean like you said: > > And added it to context xml: > > > If I don't call static shutdown() in MainApplication#stop(), like below: > > > After manual stop web app from Tomcat web manager, the memory leaks still > are there. Logs as below: > > you can see the AbstractInactivityMonitor is still running. > > If I call static shutdown() in MainApplication#stop(), and also in > MyDisposableBean, logs look different: > > > After double call static shutdown(), > thread [writeCheck] is gone after "java.lang.ClassNotFoundException: > org.apache.activemq.transport.AbstractInactivityMonitor$3". > Thread [InactivityMonitor ReadCheck] and [ActiveMQ Transport: > tcp://foo/15.87.14.93:61616] are still there, but after few seconds, they > are gone around 10:06:44.170 finally. > At the end, FailoverTransport even tried to reconnect...weird. > > I hope there is better solution on this issue. > Thank you again, Gary. > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Old-issue-Memory-leak-after-stop-web-application-in-Tomcat-tp4653959p4654187.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. -- http://fusesource.com http://blog.garytully.com
