[
https://issues.apache.org/activemq/browse/AMQ-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62167#action_62167
]
Timothy Bish commented on AMQ-2944:
-----------------------------------
Have you tried with the v5.4.1 release of ActiveMQ, there were some changes in
the FailoverTransport that might have resolved your issue.
> 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/activemq/browse/AMQ-2944
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.3.1
> Reporter: Rob Arciere
>
> 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.
-
You can reply to this email to add a comment to the issue online.
