You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Endre Stølsvik <Ap...@stolsvik.com> on 2006/11/15 10:19:46 UTC

(Second try) Lingering "ActiveMQ Scheduler" threads

Hi!

(Trying this again, due to no response last time.)

-----------

Hi!

After shutting down an instance of ClassPathXmlApplicationContext that
defines a Broker, and getting these lines in the log (amongst others, of
course):

222953 [main] DEBUG
org.springframework.beans.factory.support.DisposableBeanAdapter  -
Applying DestructionAwareBeanPostProcessors to bean with name
'org.apache.activemq.xbean.XBeanBrokerService'
222953 [main] DEBUG
org.springframework.beans.factory.support.DisposableBeanAdapter  -
Invoking destroy() on bean with name
'org.apache.activemq.xbean.XBeanBrokerService'
222953 [main] INFO org.apache.activemq.broker.BrokerService  - ActiveMQ
Message Broker (localhost, ID:endrehome-41116-1163286463312-0:1) is
shutting down
227250 [main] INFO org.apache.activemq.broker.TransportConnector  -
Connector tcp://localhost:54000 Stopped
227250 [main] INFO org.apache.activemq.broker.BrokerService  - ActiveMQ
JMS Message Broker (localhost, ID:endrehome-41116-1163286463312-0:1) stopped
227250 [main] DEBUG
org.springframework.beans.factory.support.DisposableBeanAdapter  -
Invoking custom destroy method on bean with name
'org.apache.activemq.xbean.XBeanBrokerService'
227250 [main] DEBUG
org.springframework.beans.factory.support.DefaultListableBeanFactory  -
Retrieved dependent beans for bean '(inner bean)#1':
[org.apache.activemq.xbean.XBeanBrokerService]
227250 [main] DEBUG
org.springframework.beans.factory.support.DisposableBeanAdapter  -
Applying DestructionAwareBeanPostProcessors to bean with name '(inner
bean)#1'

.. there are still 5 threads named "ActiveMQ Scheduler" running.

Broker is configured simple as follows:
<amq:broker useJmx="false" persistent="false">
   <amq:transportConnectors>
     <amq:transportConnector uri="tcp://localhost:54000" />
   </amq:transportConnectors>
</amq:broker>

The reason for noticing, is that i have this "reboot" functionality in
an application, and after the full springContext.close(), before the new
ClassPathXmlApplicationContext(<same spring config file>), these threads
are still around.

However, repeatedly "rebooting" does not build up a whole bunch of
these, which leads me to believe that ActiveMQ actually let them linger
on purpose, noticing that they're there already on next startup..

On VM-exit (simply exiting main, after calling close on the Spring
context), the whole things shuts nicely down (shutdownhooks?).

Is this on purpose, and if so, is there a way that I can get ActiveMQ to
_really really_ shut fully down? (Underlying point is that I'd like the
whole thing to be fully GC-able, basically not referencing any object
whatsoever - I want to have full control of the resource usage here..).

Thanks,
Kind regards,
Endre.

Re: (Second try) Lingering "ActiveMQ Scheduler" threads

Posted by Hiram Chirino <hi...@hiramchirino.com>.
I think that's currently only because the threads are deamon threads.
But all thread pools do have a shutdown method.

On 11/15/06, Endre Stølsvik <Ap...@stolsvik.com> wrote:
> Hiram Chirino wrote:
> > Hi that's not supported right now but perhaps with some reference
> > counting we can do full shutdowns of that thread pool.  Send us a
> > patch and we will try to get it integrated!
> >
>
> Well, okay, but is there some way to "force" it down? ("I know it you're
> shut down - kill your pools too"-method)
>
> Regards,
> Endre
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com

Re: (Second try) Lingering "ActiveMQ Scheduler" threads

Posted by Endre Stølsvik <Ap...@stolsvik.com>.
Hiram Chirino wrote:
> Hi that's not supported right now but perhaps with some reference
> counting we can do full shutdowns of that thread pool.  Send us a
> patch and we will try to get it integrated!
> 

Well, okay, but is there some way to "force" it down? ("I know it you're 
shut down - kill your pools too"-method)

Regards,
Endre

Re: (Second try) Lingering "ActiveMQ Scheduler" threads

Posted by Hiram Chirino <hi...@hiramchirino.com>.
Hi that's not supported right now but perhaps with some reference
counting we can do full shutdowns of that thread pool.  Send us a
patch and we will try to get it integrated!

On 11/15/06, Endre Stølsvik <Ap...@stolsvik.com> wrote:
> Hi!
>
> (Trying this again, due to no response last time.)
>
> -----------
>
> Hi!
>
> After shutting down an instance of ClassPathXmlApplicationContext that
> defines a Broker, and getting these lines in the log (amongst others, of
> course):
>
> 222953 [main] DEBUG
> org.springframework.beans.factory.support.DisposableBeanAdapter  -
> Applying DestructionAwareBeanPostProcessors to bean with name
> 'org.apache.activemq.xbean.XBeanBrokerService'
> 222953 [main] DEBUG
> org.springframework.beans.factory.support.DisposableBeanAdapter  -
> Invoking destroy() on bean with name
> 'org.apache.activemq.xbean.XBeanBrokerService'
> 222953 [main] INFO org.apache.activemq.broker.BrokerService  - ActiveMQ
> Message Broker (localhost, ID:endrehome-41116-1163286463312-0:1) is
> shutting down
> 227250 [main] INFO org.apache.activemq.broker.TransportConnector  -
> Connector tcp://localhost:54000 Stopped
> 227250 [main] INFO org.apache.activemq.broker.BrokerService  - ActiveMQ
> JMS Message Broker (localhost, ID:endrehome-41116-1163286463312-0:1) stopped
> 227250 [main] DEBUG
> org.springframework.beans.factory.support.DisposableBeanAdapter  -
> Invoking custom destroy method on bean with name
> 'org.apache.activemq.xbean.XBeanBrokerService'
> 227250 [main] DEBUG
> org.springframework.beans.factory.support.DefaultListableBeanFactory  -
> Retrieved dependent beans for bean '(inner bean)#1':
> [org.apache.activemq.xbean.XBeanBrokerService]
> 227250 [main] DEBUG
> org.springframework.beans.factory.support.DisposableBeanAdapter  -
> Applying DestructionAwareBeanPostProcessors to bean with name '(inner
> bean)#1'
>
> .. there are still 5 threads named "ActiveMQ Scheduler" running.
>
> Broker is configured simple as follows:
> <amq:broker useJmx="false" persistent="false">
>    <amq:transportConnectors>
>      <amq:transportConnector uri="tcp://localhost:54000" />
>    </amq:transportConnectors>
> </amq:broker>
>
> The reason for noticing, is that i have this "reboot" functionality in
> an application, and after the full springContext.close(), before the new
> ClassPathXmlApplicationContext(<same spring config file>), these threads
> are still around.
>
> However, repeatedly "rebooting" does not build up a whole bunch of
> these, which leads me to believe that ActiveMQ actually let them linger
> on purpose, noticing that they're there already on next startup..
>
> On VM-exit (simply exiting main, after calling close on the Spring
> context), the whole things shuts nicely down (shutdownhooks?).
>
> Is this on purpose, and if so, is there a way that I can get ActiveMQ to
> _really really_ shut fully down? (Underlying point is that I'd like the
> whole thing to be fully GC-able, basically not referencing any object
> whatsoever - I want to have full control of the resource usage here..).
>
> Thanks,
> Kind regards,
> Endre.
>


-- 
Regards,
Hiram

Blog: http://hiramchirino.com