activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From edbras <>
Subject Re: When will activemq-core 5.9 be present in maven central repo?
Date Fri, 06 Dec 2013 13:00:41 GMT
> if you're using a pool, usually the pool is in charge of shutting down
I am using the Spring pool:

And yes, I think the order is incorrect, what I can tell from the logging.
>From the logging:
 13:43:53.103 [Thread-7]  INFO  o.s.b.f.s.DefaultListableBeanFactory -
Destroying singletons in .....
 13:43:53.103 [Thread-7]  DEBUG o.s.b.f.s.DisposableBeanAdapter - Invoking
destroy method 'destroy' on    bean with name 'jmsBroker'
13:43:53.123 [xecutor: vm://localhost#0]  WARN 
o.s.j.c.CachingConnectionFactory - Encountered a JMSException - resetting
the underlying JMS Connection
javax.jms.JMSException: peer (vm://localhost#1) stopped.
 >>> EXCEPTION  <<<
13:43:53.602 [Thread-7]  DEBUG o.s.b.f.s.DisposableBeanAdapter - Invoking
destroy() on bean with name 'jmsConnectionFactory' (CachingConnectionFactory

I think 
1) It should first call the destroy on the CachingConnectionFactory  and
then on the jms Broker. 
2) Or the jms broker should leave alone the CachingConnectionFactory when
it's being stopped?

I went for 1) by putting a "depends-on" on the CachingConnectionFactory bean
to the jms broker bean such that the broker always is created before the
connection factory. And Spring always (tries) to destroy the beans in the
reversed order they were created.

And it works ;)

(BTW: any idea what changed such that I didn't got this exception in 5.7.0?)
BTW: The above exception occurred with the shutdown hook on the Spring
context (not on the broker).

Thanks for the advice.

View this message in context:
Sent from the ActiveMQ - User mailing list archive at

View raw message