One approach that may work for you: stand up new brokers with the upgrade, temporarily network the old broker to the new, force all clients to reconnect to the new.
In order for that to work, the clients need to know to connect to the new brokers before they are stood up. The failover transport can do the job. Then you need a way to bridge the brokers. There's a tool I started, https://github.com/amlinv/ActiveMQBridgeController, which can do the job. It's in the early stages, but it does provide a browser-based UI to configure, start, and stop bridges. On the other hand, upgrading a broker should generally be a quick operation. So, that begs the question, "how much complexity and risk should be introduced to eliminate the downtime?" -- View this message in context: http://activemq.2283324.n4.nabble.com/5-9-to-5-10-Upgrade-tp4686426p4686597.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
