> if you're using a pool, usually the pool is in charge of shutting down connections. I am using the Spring pool: org.springframework.jms.connection.CachingConnectionFactory
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: http://activemq.2283324.n4.nabble.com/When-will-activemq-core-5-9-be-present-in-maven-central-repo-tp4675087p4675246.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
