ActiveMQ Classic迁移至ActiveMQ Artemis故障转移失效问题咨询

结论 #

你遇到的客户端无法自动重连的情况不属于正常现象，核心是Artemis的OpenWire协议配套配置缺失、和原有Classic集群的客户端拓扑推送机制不兼容导致的。

问题根因 #

1. 原有ActiveMQ Classic的传输连接器开启了updateClusterClients、updateClusterClientsOnRemove、rebalanceClusterClients参数，会主动向连接的OpenWire客户端推送最新的集群节点拓扑，客户端的FailoverTransport会动态更新可连接的节点列表。但你当前的Artemis配置中，OpenWire协议的acceptor没有开启对应的拓扑推送参数，客户端无法获取更新后的节点信息，重连时只能用初始配置的固定地址列表。
2. 你的Artemis配置存在笔误：invm acceptor的配置多了一个多余的前置双引号，会导致内部连接初始化异常。
3. Artemis与ActiveMQ Classic的集群互通机制不兼容，Classic的网络连接器（networkConnector）无法和Artemis的集群连接（cluster-connection）直接通信，滚动升级过程中单节点切换后，跨版本的两个节点无法形成统一集群，也会影响客户端的路由感知。

修复方案 #

1. 修正Artemis的配置笔误，将invm acceptor调整为：

<acceptor name="invm">vm://0</acceptor>

2. 给Artemis的OpenWire acceptor添加拓扑推送和传输参数匹配配置，调整后的netty-acceptor如下：

<acceptor name="netty-acceptor">tcp://172.17.233.92:63616?protocols=OPENWIRE;openWireUpdateClusterClients=true;openWireUpdateClusterClientsOnRemove=true;openWireRebalanceClusterClients=true;soTimeout=30000;soWriteTimeout=30000;keepAlive=true</acceptor>

3. 滚动升级期间可以临时调整客户端FailoverTransport的重试参数，将maxReconnectAttempts设为-1（无限重试），适当拉长重试间隔，避免短时间重试耗尽次数后停止重连。
4. 完成两个节点全部升级到Artemis后，再验证集群互通和客户端重连逻辑，即可完全恢复原有滚动升级不中断业务的能力。

内容的提问来源于stack exchange，提问作者Nicolas Verducou