[AMQ-5412] Failover transport: disconnect existing connection when priorityBackup=true and priority broker becomes available, if maxReconnectAttempts=0

• Type: New Feature
• Status: Closed
• Priority: Major
• Resolution: Abandoned
• Affects Version/s: 5.6.0
• Component/s: Broker
• Assignee: Unassigned
• Reporter: Tim Bain
• Created: 24/Oct/14 19:59
• Updated: 13/Mar/22 14:08
• Resolved: 13/Mar/22 14:08

Description

NOTE: This enhancement request is purely a workaround because AMQ-5411 isn't implemented yet. If that issue was going to be fixed in the near term, it's probably not worth implementing this (though maybe it would still be valuable in limited situations).

The static transport does not support reconnections by its underlying transports such as failover; rather, it requires that those underlying transports allow their transports to fail and bubble up to the static transport, so that the static transport can reconnect and also recreate the network bridges.

This limitation means that the failover transport can't use the priorityBackup feature to fail back to the primary broker when it's available. This means that when all of the clients are back on the primary (because they can use priorityBackup happily), the broker-to-broker connections are still pointing to the backup, requiring an extra network hop (which might go over low-performance backup-only network links, depending on the network configuration) for messages to get to consumers. And there is currently no workaround to make this feature work even if it requires unintuitive configuration options.

As a short-term workaround, when maxReconnectAttempts=0 and we detect that the priority broker is back up we should abort both the new connection and the old one. This will cause us to bubble up the failure to the static transport, which will reconnect the network bridges and allow us to resume operations.

Maybe we should do this for values of maxReconnectAttempts other than 0, but I don't know those use cases well enough to say for sure.

Issue Links

• is related to: AMQ-3798 Network connector does not establish connections to a slave broker after master failure
• is related to: AMQ-4720 Messages lost after fail-back of a network connector using priorityBackup=true - reason is that remote broker isn't checking producerID & is rejecting because of duplicate producerSequence