ActiveMQ Classic故障转移连接串正确性及参数验证咨询

针对你使用的Apache.NMS.ActiveMQ 1.8.0（.NET Core 6）和ActiveMQ Broker 5.13.2，正确的故障转移连接串需要区分故障转移传输自身参数和底层TCP传输参数：

activemq:failover:(tcp://brokera.domain.net:21249,tcp://brokerb.domain.net:21249)?maxReconnectAttempts=2&transport.timeout=3000&initialReconnectDelay=2000

参数规则说明 #

• 无需transport.前缀的参数：maxReconnectAttempts、initialReconnectDelay属于故障转移（failover）传输的核心配置，直接控制重连逻辑，这类参数不需要前缀，直接写在连接串的查询参数中即可。
• 需要transport.前缀的参数：timeout是底层TCP传输的连接超时参数，故障转移传输本身不识别该参数，必须通过transport.前缀将其传递给内部的TCP transport，否则该参数会被忽略，客户端将使用TCP传输的默认超时值。

你之前测试中两种格式都能工作，是因为测试场景下超时参数未触发（或者默认超时足够短），但无前缀的timeout实际上并未生效，生产环境中可能因默认超时过长导致连接等待时间超出预期。

针对每个参数的验证，可以通过日志监控和代码调试结合的方式进行：

1. 验证maxReconnectAttempts（最大重连次数） #

• 操作步骤：关闭所有ActiveMQ Broker节点，启动客户端应用
• 验证方式：
  • 查看客户端日志（需配置日志框架输出Apache.NMS.ActiveMQ的调试日志），日志中会输出重连尝试的记录，统计次数应恰好等于设置的2次，之后不再发起重连。
  • 代码层面：监听ConnectionInterrupted事件，统计触发次数，当达到最大重连次数后，客户端会抛出ConnectionFailedException。

2. 验证transport.timeout（TCP连接超时） #

• 操作步骤：修改连接串中的Broker地址为一个不存在的IP/端口，或通过防火墙阻断该端口，启动客户端
• 验证方式：
  • 记录从客户端发起连接到抛出超时异常的时间，该时间应接近设置的3000ms（3秒），而非TCP传输的默认超时（通常更长）。

3. 验证initialReconnectDelay（初始重连延迟） #

• 操作步骤：先启动一个Broker节点，让客户端成功建立连接；然后关闭该Broker，观察客户端的重连行为
• 验证方式：
  • 查看日志中的时间戳，第一次重连尝试应在Broker断开后的2000ms（2秒）后触发，而非立即重试。

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