[
https://issues.apache.org/jira/browse/AMQ-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish resolved AMQ-2944.
-------------------------------
Resolution: Fixed
Fix Version/s: 5.5.0
This should be resolved with the changes for updating the cluster client's and
not using the broker infos to populate the uri's for the failover transport.
> Failover transport always re-connects to the first configured transport
> instead of the original transport speficied in the connection url
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: AMQ-2944
> URL: https://issues.apache.org/jira/browse/AMQ-2944
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.3.1
> Reporter: Rob Arciere
> Fix For: 5.5.0
>
> Attachments: activemq.xml
>
>
> I am using a single broker configured to accept both tcp and ssl connections
> using the configuration below
> <transportConnectors>
> <transportConnector name="openwire" uri="tcp://0.0.0.0:61616"/>
> <transportConnector name="ssl" uri="ssl://0.0.0.0:61617"/>
> </transportConnectors>
> The clients are configured to use the failover transport over ssl to connect
> to a single broker (e.g. URL: failover:ssl://Host:61616). Upon startup the
> client correctly connects to the broker on port 61617 via ssl. I then
> simulate a network outage and the transport is interrupted and waits for the
> connection to become available. After a short amount of time the Broker
> detects inactivity on the connection and then drops the connection (viewed
> via JMX and Jconsole). When the network connection is restored, the client
> reconnects to broker on port 61616 using tcp instead of ssl on port 61617
> (not good if you require ssl encryption).
> It appears that the ordering of the transportConnectors in the activemq.xml
> file affects which transport is used upon resumption of an interrupted
> failover transport. It turns out that upon reconnection the first defined
> transport will always be used regardless of what transport was specified in
> the original client connection url. Changing the ordering to the following
> fixes the problem and upon reconnection the ssl transport will be used.
> However, the reverse issue will occur for clients that originally connection
> via tcp transport where upon reconnection they will connect via ssl transport
> instead of tcp.
> <transportConnectors>
> <transportConnector name="ssl" uri="ssl://0.0.0.0:61617"/>
> <transportConnector name="openwire" uri="tcp://0.0.0.0:61616"/>
> </transportConnectors>
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
