I'm working on some code to check Exceptions to see if it was a connection problem, and if so, loop and try and get a new connection in order to re-connect and continue publishing messages after the broker comes back up. I'm using an org.apache.activemq.pool.PooledConnectionFactory, with the MaxConnections set to 20. When I start my application up, I get 20 ActiveMQ Transport threads running. I've called PooledConnectionFactory.start(), so I assume this is normal as it pre-started all 20 Connections.
When I intentionally shutdown my broker to test it (not a hard kill, just a shutdown), I get a 20 ActiveMQ Connection Worker threads running. When I bring the broker back up and it re-establishes a connection, I get the 20 ActiveMQ Transport threads back, but the Connection Work threads are still hanging around. When I take a closer look, the Worker threads are part of some ThreadPoolExecutor. They don't appear to timeout, and just sit there. They are sitting waiting on LinkedBlockingQueue.take(), so since it seems that nothing really is going on, I'm guessing nothing is being put on the Thread Pool. Is this Thread Pool supposed to be shutdown? Are the worker threads supposed to be actually doing something? Is there something I should be doing in my code to tell it to shut these down properly, or to have the ActiveMQ client library do its own reconnection without me having to do much if any work? This is all on v5.1. My sysadmin is rather conservative when it comes to version upgrades. -- View this message in context: http://www.nabble.com/Reconnection-after-broker-goes-down%2C-then-back-up-tp25998150p25998150.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
