activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Bain (JIRA)" <j...@apache.org>
Subject [jira] [Created] (AMQ-5411) Rewrite static: transport to let it respond to reconnections by failover: transports within it
Date Fri, 24 Oct 2014 19:59:35 GMT
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)

Mime
View raw message