You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Tim Bain (JIRA)" <ji...@apache.org> on 2014/10/24 21:59:35 UTC

[jira] [Created] (AMQ-5411) Rewrite static: transport to let it respond to reconnections by failover: transports within it

Tim Bain created AMQ-5411:
-----------------------------

             Summary: Rewrite static: transport to let it respond to reconnections by failover: transports within it
                 Key: AMQ-5411
                 URL: https://issues.apache.org/jira/browse/AMQ-5411
             Project: ActiveMQ
          Issue Type: New Feature
          Components: Broker
    Affects Versions: 5.x
            Reporter: Tim Bain


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.

To support this limitation, we have to configure maxReconnectAttempts=0 on the failover transport when wrapped in the static transport (for use in a broker-to-broker networkConnection), allowing the static transport to perform reconnection logic and simply using the failover transport to pick the underlying URI to use.  This is a non-intuitive workaround that can trip up users trying to use failover on broker-to-broker connections, but at least one exists.

However, the limitation also 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.

We should rewrite the code for the static transport to allow it to be notified when its underlying transports failover to another connection (perhaps via the DiscoveryListener interface?), without requiring that the underlying transport allow itself to fail and bubble out to the static transport.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)