我找不到有关 JMS 客户端重新连接如何与故障转移逻辑配合使用的明确文档。 我查阅了以下官方文档，与我使用的版本相对应:
JMS 客户端指定以下 URI 来进行故障转移和重试:
String uri = new String("failover:(amqp://host1:5672,amqp://host2:5672)?&failover.maxReconnectAttempts=20");
javax.jms.ConnectionFactory connectionFactory = new org.apache.qpid.jms.JmsConnectionFactory(uri);
failover.maxReconnectAttempts 是否应用于每个故障转移 URI(即，将在第一个 URI 上重试 20 次，如果重新连接失败，将在第二个 URI 上再尝试 20 次；对我来说，这里需要注意的是，默认最大重新连接值为 -1，客户端将无限期地在第一个 URI 上重试，因此故障转移逻辑永远不会到达第二个 URI)，或者是在两个 URI 上循环(即对第一个 URI 重试一次，然后对第二个 URI 也重试一次，然后返回第一个 URI，依此类推...总共重试 20 次)？我当然会对此进行测试，但是官方标准中是否解释了这种行为？
假设客户端正在发送或接收消息，并且与 host1 上的代理存在连接问题，是否也会重试发送或接收操作？我希望重试底层连接，但是不确定发送或接收操作会发生什么。如果发送/接收没有自动重试，则意味着在发送/接收级别上必须有另一个重试逻辑(我认为这不太可能)。和以前一样，官方标准中有记录吗？
最佳答案
AMQP 客户端如何管理故障转移没有规范定义的行为，因此不同的实现会有所不同。对于 Qpid JMS 的过时版本，您使用的客户端我认为(不再记得了)将每次尝试连接到远程 URI 视为一次不同的尝试，因此如果您配置的尝试次数少于要连接的 URI，则可能会错过 URI .
故障转移重试逻辑在 v0.26.0 左右进行了彻底修改，现在更加强大和可预测，因此您确实应该很快迁移到最新版本 0.35.0
发送和接收处理的工作方式取决于连接断开的过程中的位置。大多数情况下，都会重试发送，但有几个小时间窗口，您可能会收到指示发送失败的异常。对于接收来说，事情更加困难，因为由远程决定当连接断开时 Unresolved 传递会发生什么，它有权将该消息发送到其他地方。
即使使用故障转移，您也需要处理 JMS 异常并练习良好的编码方法，因为不存在完全透明的故障转移，并且您需要做好在发生意外情况时使用react的准备。
关于java - AMQP 重试连接如何与故障转移配合使用？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/51406374/