Tim Bain created AMQ-5412:
-----------------------------
Summary: Failover transport: disconnect existing connection when
priorityBackup=true and priority broker becomes available, if
maxReconnectAttempts=0
Key: AMQ-5412
URL: https://issues.apache.org/jira/browse/AMQ-5412
Project: ActiveMQ
Issue Type: New Feature
Components: Broker
Affects Versions: 5.6.0
Reporter: Tim Bain
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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
