You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Adam Sussman (JIRA)" <ji...@apache.org> on 2011/01/08 02:59:46 UTC
[jira] Created: (AMQ-3124) Failover transport client gets corrupted
connectedBrokers data
Failover transport client gets corrupted connectedBrokers data
---------------------------------------------------------------
Key: AMQ-3124
URL: https://issues.apache.org/jira/browse/AMQ-3124
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.4.2
Reporter: Adam Sussman
When clients use the Failover transport, the broker will deliver a list of brokers it peers with to the client. This happens on initial connection and, if configured, as brokers come in and out of the cluster.
The problem is that the entire URI is given, including query string information. If the query string contains commas in it then the Failover client breaks it up into unusable client uris and will attempt to connect to them. Also, in 5.4.2, this leads to the same failure that occurs in AMQ-3085.
Also, there doesn't seem to be a point in the client trying to use the same query string parameters that the server is using.
Attached patch strips the query string before sending uris to the client.
Example:
Broker1:
<transportConnectors>
<transportConnector name="openwire+ssl" uri="ssl://0.0.0.0:61616?needClientAuth=true&enabledCipherSuites=SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA" />
</transportConnectors>
Broker2:
<networkConnectors>
<networkConnector name="core1" uri="static:(ssl://broker1:61616)" duplex="true" />
</networkConnectors>
<transportConnectors>
<transportConnector name="openwire+ssl" uri="ssl://0.0.0.0:61616?needClientAuth=true" />
</transportConnectors>
With a client connecting to: failover:(ssl://broker2:61616), you will see (extra debugging added by me):
[DEBUG] FailoverTransport - Failover add: u[0] is: ssl://broker2:61616
[DEBUG] FailoverTransport - Reconnect was triggered but transport is not started yet. Wait for start to connect the transport.
[DEBUG] FailoverTransport - Started.
[DEBUG] FailoverTransport - Waking up reconnect task
[DEBUG] FailoverTransport - urlList connectionList:[ssl://broker2:61616]
[DEBUG] FailoverTransport - Attempting connect to: ssl://broker2:61616
[DEBUG] FailoverTransport - Failover add: u[0] is: TLS_RSA_WITH_AES_256_CBC_SHA
[DEBUG] FailoverTransport - Failover add: u[1] is: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
[DEBUG] FailoverTransport - Failover add: u[2] is: TLS_RSA_WITH_AES_128_CBC_SHA
[DEBUG] FailoverTransport - Failover add: u[3] is: TLS_DHE_RSA_WITH_AES_128_CBC_SHA
[DEBUG] FailoverTransport - Failover add: u[4] is: ssl://broker2:61616?needClientAuth=true&enabledCipherSuites=SSL_RSA_WITH_RC4_128_SHA
[DEBUG] FailoverTransport - Failover add: u[5] is: TLS_DHE_DSS_WITH_AES_128_CBC_SHA
[DEBUG] FailoverTransport - Failover add: u[6] is: ssl://broker1:61616?needClientAuth=true
[WARN] FailoverTransport - Transport (broker2/10.73.76.102:61616) failed to ssl://broker2:61616 , attempting to automatically reconnect due to: java.io.IOException: Unexpected error occured
[DEBUG] FailoverTransport - Transport failed with the following exception: <java.io.IOException: Unexpected error occured>java.io.IOException: Unexpected error occured
at org.apache.activemq.transport.failover.FailoverTransport.add(FailoverTransport.java:614)
at org.apache.activemq.transport.failover.FailoverTransport.updateURIs(FailoverTransport.java:1049)
at org.apache.activemq.transport.failover.FailoverTransport.processNewTransports(FailoverTransport.java:285)
at org.apache.activemq.transport.failover.FailoverTransport.handleConnectionControl(FailoverTransport.java:265)
at org.apache.activemq.transport.failover.FailoverTransport$3.onCommand(FailoverTransport.java:177)
[DEBUG] FailoverTransport - urlList connectionList:[TLS_RSA_WITH_AES_256_CBC_SHA, ssl://broker2:61616]
[DEBUG] FailoverTransport - Attempting connect to: TLS_RSA_WITH_AES_256_CBC_SHA
[DEBUG] FailoverTransport - Connect fail to: TLS_RSA_WITH_AES_256_CBC_SHA, reason: java.io.IOException: Transport not scheme specified: [TLS_RSA_WITH_AES_256_CBC_SHA]
[DEBUG] FailoverTransport - Attempting connect to: ssl://broker2:61616
[DEBUG] FailoverTransport - Connection established
[INFO] FailoverTransport - Successfully reconnected to ssl://broker2:61616
Note that the stacktrace occurs for the same reason as AMQ-3085, but all the extra work attempting to connect to invalid uris is wasteful. Also, the client has no need for the query string parameters of the server uris.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AMQ-3124) Failover transport client gets
corrupted connectedBrokers data
Posted by "Gary Tully (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gary Tully resolved AMQ-3124.
-----------------------------
Resolution: Fixed
Fix Version/s: 5.5.0
fix applied in r1057565
reused TransportConnetor.getPublishableConnectString() for the propagated uri in cluster update
> Failover transport client gets corrupted connectedBrokers data
> ---------------------------------------------------------------
>
> Key: AMQ-3124
> URL: https://issues.apache.org/jira/browse/AMQ-3124
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.4.2
> Reporter: Adam Sussman
> Assignee: Gary Tully
> Fix For: 5.5.0
>
> Attachments: amq-3124.patch
>
>
> When clients use the Failover transport, the broker will deliver a list of its own uri and also brokers it peers with to the client. This happens on initial connection and, if configured, as brokers come in and out of the cluster.
> The problem is that the entire URI is given, including query string information. If the query string contains commas in it then the Failover client breaks it up into unusable client uris and will attempt to connect to them. Also, in 5.4.2, this leads to the same failure that occurs in AMQ-3085.
> Also, there doesn't seem to be a point in the client trying to use the same query string parameters that the server is using.
> Attached patch strips the query string before sending uris to the client.
> Example:
> Broker1:
> <transportConnectors>
> <transportConnector name="openwire+ssl" uri="ssl://0.0.0.0:61616?needClientAuth=true&enabledCipherSuites=SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA" />
> </transportConnectors>
> With a client connecting to: failover:(ssl://broker1:61616), you will see (extra debugging added by me):
> [DEBUG] FailoverTransport - Failover add: u[0] is: ssl://broker1:61616
> [DEBUG] FailoverTransport - Reconnect was triggered but transport is not started yet. Wait for start to connect the transport.
> [DEBUG] FailoverTransport - Started.
> [DEBUG] FailoverTransport - Waking up reconnect task
> [DEBUG] FailoverTransport - urlList connectionList:[ssl://broker1:61616]
> [DEBUG] FailoverTransport - Attempting connect to: ssl://broker1:61616
> [DEBUG] FailoverTransport - Failover add: u[0] is: TLS_RSA_WITH_AES_256_CBC_SHA
> [DEBUG] FailoverTransport - Failover add: u[1] is: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
> [DEBUG] FailoverTransport - Failover add: u[2] is: TLS_RSA_WITH_AES_128_CBC_SHA
> [DEBUG] FailoverTransport - Failover add: u[3] is: TLS_DHE_RSA_WITH_AES_128_CBC_SHA
> [DEBUG] FailoverTransport - Failover add: u[4] is: ssl://broker1:61616?needClientAuth=true&enabledCipherSuites=SSL_RSA_WITH_RC4_128_SHA
> [DEBUG] FailoverTransport - Failover add: u[5] is: TLS_DHE_DSS_WITH_AES_128_CBC_SHA
> [WARN] FailoverTransport - Transport (broker1/10.73.76.102:61616) failed to ssl://broker1:61616 , attempting to automatically reconnect due to: java.io.IOException: Unexpected error occured
> [DEBUG] FailoverTransport - Transport failed with the following exception: <java.io.IOException: Unexpected error occured>java.io.IOException: Unexpected error occured
> at org.apache.activemq.transport.failover.FailoverTransport.add(FailoverTransport.java:614)
> at org.apache.activemq.transport.failover.FailoverTransport.updateURIs(FailoverTransport.java:1049)
> at org.apache.activemq.transport.failover.FailoverTransport.processNewTransports(FailoverTransport.java:285)
> at org.apache.activemq.transport.failover.FailoverTransport.handleConnectionControl(FailoverTransport.java:265)
> at org.apache.activemq.transport.failover.FailoverTransport$3.onCommand(FailoverTransport.java:177)
> [DEBUG] FailoverTransport - urlList connectionList:[TLS_RSA_WITH_AES_256_CBC_SHA, ssl://broker1:61616]
> [DEBUG] FailoverTransport - Attempting connect to: TLS_RSA_WITH_AES_256_CBC_SHA
> [DEBUG] FailoverTransport - Connect fail to: TLS_RSA_WITH_AES_256_CBC_SHA, reason: java.io.IOException: Transport not scheme specified: [TLS_RSA_WITH_AES_256_CBC_SHA]
> [DEBUG] FailoverTransport - Attempting connect to: ssl://broker1:61616
> [DEBUG] FailoverTransport - Connection established
> [INFO] FailoverTransport - Successfully reconnected to ssl://broker1:61616
> Note that the stacktrace occurs for the same reason as AMQ-3085, but all the extra work attempting to connect to invalid uris is wasteful. Also, the client has no need for the query string parameters of the server uris.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-3124) Failover transport client gets corrupted
connectedBrokers data
Posted by "Adam Sussman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adam Sussman updated AMQ-3124:
------------------------------
Description:
When clients use the Failover transport, the broker will deliver a list of its own uri and also brokers it peers with to the client. This happens on initial connection and, if configured, as brokers come in and out of the cluster.
The problem is that the entire URI is given, including query string information. If the query string contains commas in it then the Failover client breaks it up into unusable client uris and will attempt to connect to them. Also, in 5.4.2, this leads to the same failure that occurs in AMQ-3085.
Also, there doesn't seem to be a point in the client trying to use the same query string parameters that the server is using.
Attached patch strips the query string before sending uris to the client.
Example:
Broker1:
<transportConnectors>
<transportConnector name="openwire+ssl" uri="ssl://0.0.0.0:61616?needClientAuth=true&enabledCipherSuites=SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA" />
</transportConnectors>
With a client connecting to: failover:(ssl://broker1:61616), you will see (extra debugging added by me):
[DEBUG] FailoverTransport - Failover add: u[0] is: ssl://broker1:61616
[DEBUG] FailoverTransport - Reconnect was triggered but transport is not started yet. Wait for start to connect the transport.
[DEBUG] FailoverTransport - Started.
[DEBUG] FailoverTransport - Waking up reconnect task
[DEBUG] FailoverTransport - urlList connectionList:[ssl://broker1:61616]
[DEBUG] FailoverTransport - Attempting connect to: ssl://broker1:61616
[DEBUG] FailoverTransport - Failover add: u[0] is: TLS_RSA_WITH_AES_256_CBC_SHA
[DEBUG] FailoverTransport - Failover add: u[1] is: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
[DEBUG] FailoverTransport - Failover add: u[2] is: TLS_RSA_WITH_AES_128_CBC_SHA
[DEBUG] FailoverTransport - Failover add: u[3] is: TLS_DHE_RSA_WITH_AES_128_CBC_SHA
[DEBUG] FailoverTransport - Failover add: u[4] is: ssl://broker1:61616?needClientAuth=true&enabledCipherSuites=SSL_RSA_WITH_RC4_128_SHA
[DEBUG] FailoverTransport - Failover add: u[5] is: TLS_DHE_DSS_WITH_AES_128_CBC_SHA
[WARN] FailoverTransport - Transport (broker1/10.73.76.102:61616) failed to ssl://broker1:61616 , attempting to automatically reconnect due to: java.io.IOException: Unexpected error occured
[DEBUG] FailoverTransport - Transport failed with the following exception: <java.io.IOException: Unexpected error occured>java.io.IOException: Unexpected error occured
at org.apache.activemq.transport.failover.FailoverTransport.add(FailoverTransport.java:614)
at org.apache.activemq.transport.failover.FailoverTransport.updateURIs(FailoverTransport.java:1049)
at org.apache.activemq.transport.failover.FailoverTransport.processNewTransports(FailoverTransport.java:285)
at org.apache.activemq.transport.failover.FailoverTransport.handleConnectionControl(FailoverTransport.java:265)
at org.apache.activemq.transport.failover.FailoverTransport$3.onCommand(FailoverTransport.java:177)
[DEBUG] FailoverTransport - urlList connectionList:[TLS_RSA_WITH_AES_256_CBC_SHA, ssl://broker1:61616]
[DEBUG] FailoverTransport - Attempting connect to: TLS_RSA_WITH_AES_256_CBC_SHA
[DEBUG] FailoverTransport - Connect fail to: TLS_RSA_WITH_AES_256_CBC_SHA, reason: java.io.IOException: Transport not scheme specified: [TLS_RSA_WITH_AES_256_CBC_SHA]
[DEBUG] FailoverTransport - Attempting connect to: ssl://broker1:61616
[DEBUG] FailoverTransport - Connection established
[INFO] FailoverTransport - Successfully reconnected to ssl://broker1:61616
Note that the stacktrace occurs for the same reason as AMQ-3085, but all the extra work attempting to connect to invalid uris is wasteful. Also, the client has no need for the query string parameters of the server uris.
was:
When clients use the Failover transport, the broker will deliver a list of brokers it peers with to the client. This happens on initial connection and, if configured, as brokers come in and out of the cluster.
The problem is that the entire URI is given, including query string information. If the query string contains commas in it then the Failover client breaks it up into unusable client uris and will attempt to connect to them. Also, in 5.4.2, this leads to the same failure that occurs in AMQ-3085.
Also, there doesn't seem to be a point in the client trying to use the same query string parameters that the server is using.
Attached patch strips the query string before sending uris to the client.
Example:
Broker1:
<transportConnectors>
<transportConnector name="openwire+ssl" uri="ssl://0.0.0.0:61616?needClientAuth=true&enabledCipherSuites=SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA" />
</transportConnectors>
Broker2:
<networkConnectors>
<networkConnector name="core1" uri="static:(ssl://broker1:61616)" duplex="true" />
</networkConnectors>
<transportConnectors>
<transportConnector name="openwire+ssl" uri="ssl://0.0.0.0:61616?needClientAuth=true" />
</transportConnectors>
With a client connecting to: failover:(ssl://broker2:61616), you will see (extra debugging added by me):
[DEBUG] FailoverTransport - Failover add: u[0] is: ssl://broker2:61616
[DEBUG] FailoverTransport - Reconnect was triggered but transport is not started yet. Wait for start to connect the transport.
[DEBUG] FailoverTransport - Started.
[DEBUG] FailoverTransport - Waking up reconnect task
[DEBUG] FailoverTransport - urlList connectionList:[ssl://broker2:61616]
[DEBUG] FailoverTransport - Attempting connect to: ssl://broker2:61616
[DEBUG] FailoverTransport - Failover add: u[0] is: TLS_RSA_WITH_AES_256_CBC_SHA
[DEBUG] FailoverTransport - Failover add: u[1] is: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
[DEBUG] FailoverTransport - Failover add: u[2] is: TLS_RSA_WITH_AES_128_CBC_SHA
[DEBUG] FailoverTransport - Failover add: u[3] is: TLS_DHE_RSA_WITH_AES_128_CBC_SHA
[DEBUG] FailoverTransport - Failover add: u[4] is: ssl://broker2:61616?needClientAuth=true&enabledCipherSuites=SSL_RSA_WITH_RC4_128_SHA
[DEBUG] FailoverTransport - Failover add: u[5] is: TLS_DHE_DSS_WITH_AES_128_CBC_SHA
[DEBUG] FailoverTransport - Failover add: u[6] is: ssl://broker1:61616?needClientAuth=true
[WARN] FailoverTransport - Transport (broker2/10.73.76.102:61616) failed to ssl://broker2:61616 , attempting to automatically reconnect due to: java.io.IOException: Unexpected error occured
[DEBUG] FailoverTransport - Transport failed with the following exception: <java.io.IOException: Unexpected error occured>java.io.IOException: Unexpected error occured
at org.apache.activemq.transport.failover.FailoverTransport.add(FailoverTransport.java:614)
at org.apache.activemq.transport.failover.FailoverTransport.updateURIs(FailoverTransport.java:1049)
at org.apache.activemq.transport.failover.FailoverTransport.processNewTransports(FailoverTransport.java:285)
at org.apache.activemq.transport.failover.FailoverTransport.handleConnectionControl(FailoverTransport.java:265)
at org.apache.activemq.transport.failover.FailoverTransport$3.onCommand(FailoverTransport.java:177)
[DEBUG] FailoverTransport - urlList connectionList:[TLS_RSA_WITH_AES_256_CBC_SHA, ssl://broker2:61616]
[DEBUG] FailoverTransport - Attempting connect to: TLS_RSA_WITH_AES_256_CBC_SHA
[DEBUG] FailoverTransport - Connect fail to: TLS_RSA_WITH_AES_256_CBC_SHA, reason: java.io.IOException: Transport not scheme specified: [TLS_RSA_WITH_AES_256_CBC_SHA]
[DEBUG] FailoverTransport - Attempting connect to: ssl://broker2:61616
[DEBUG] FailoverTransport - Connection established
[INFO] FailoverTransport - Successfully reconnected to ssl://broker2:61616
Note that the stacktrace occurs for the same reason as AMQ-3085, but all the extra work attempting to connect to invalid uris is wasteful. Also, the client has no need for the query string parameters of the server uris.
> Failover transport client gets corrupted connectedBrokers data
> ---------------------------------------------------------------
>
> Key: AMQ-3124
> URL: https://issues.apache.org/jira/browse/AMQ-3124
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.4.2
> Reporter: Adam Sussman
> Attachments: amq-3124.patch
>
>
> When clients use the Failover transport, the broker will deliver a list of its own uri and also brokers it peers with to the client. This happens on initial connection and, if configured, as brokers come in and out of the cluster.
> The problem is that the entire URI is given, including query string information. If the query string contains commas in it then the Failover client breaks it up into unusable client uris and will attempt to connect to them. Also, in 5.4.2, this leads to the same failure that occurs in AMQ-3085.
> Also, there doesn't seem to be a point in the client trying to use the same query string parameters that the server is using.
> Attached patch strips the query string before sending uris to the client.
> Example:
> Broker1:
> <transportConnectors>
> <transportConnector name="openwire+ssl" uri="ssl://0.0.0.0:61616?needClientAuth=true&enabledCipherSuites=SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA" />
> </transportConnectors>
> With a client connecting to: failover:(ssl://broker1:61616), you will see (extra debugging added by me):
> [DEBUG] FailoverTransport - Failover add: u[0] is: ssl://broker1:61616
> [DEBUG] FailoverTransport - Reconnect was triggered but transport is not started yet. Wait for start to connect the transport.
> [DEBUG] FailoverTransport - Started.
> [DEBUG] FailoverTransport - Waking up reconnect task
> [DEBUG] FailoverTransport - urlList connectionList:[ssl://broker1:61616]
> [DEBUG] FailoverTransport - Attempting connect to: ssl://broker1:61616
> [DEBUG] FailoverTransport - Failover add: u[0] is: TLS_RSA_WITH_AES_256_CBC_SHA
> [DEBUG] FailoverTransport - Failover add: u[1] is: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
> [DEBUG] FailoverTransport - Failover add: u[2] is: TLS_RSA_WITH_AES_128_CBC_SHA
> [DEBUG] FailoverTransport - Failover add: u[3] is: TLS_DHE_RSA_WITH_AES_128_CBC_SHA
> [DEBUG] FailoverTransport - Failover add: u[4] is: ssl://broker1:61616?needClientAuth=true&enabledCipherSuites=SSL_RSA_WITH_RC4_128_SHA
> [DEBUG] FailoverTransport - Failover add: u[5] is: TLS_DHE_DSS_WITH_AES_128_CBC_SHA
> [WARN] FailoverTransport - Transport (broker1/10.73.76.102:61616) failed to ssl://broker1:61616 , attempting to automatically reconnect due to: java.io.IOException: Unexpected error occured
> [DEBUG] FailoverTransport - Transport failed with the following exception: <java.io.IOException: Unexpected error occured>java.io.IOException: Unexpected error occured
> at org.apache.activemq.transport.failover.FailoverTransport.add(FailoverTransport.java:614)
> at org.apache.activemq.transport.failover.FailoverTransport.updateURIs(FailoverTransport.java:1049)
> at org.apache.activemq.transport.failover.FailoverTransport.processNewTransports(FailoverTransport.java:285)
> at org.apache.activemq.transport.failover.FailoverTransport.handleConnectionControl(FailoverTransport.java:265)
> at org.apache.activemq.transport.failover.FailoverTransport$3.onCommand(FailoverTransport.java:177)
> [DEBUG] FailoverTransport - urlList connectionList:[TLS_RSA_WITH_AES_256_CBC_SHA, ssl://broker1:61616]
> [DEBUG] FailoverTransport - Attempting connect to: TLS_RSA_WITH_AES_256_CBC_SHA
> [DEBUG] FailoverTransport - Connect fail to: TLS_RSA_WITH_AES_256_CBC_SHA, reason: java.io.IOException: Transport not scheme specified: [TLS_RSA_WITH_AES_256_CBC_SHA]
> [DEBUG] FailoverTransport - Attempting connect to: ssl://broker1:61616
> [DEBUG] FailoverTransport - Connection established
> [INFO] FailoverTransport - Successfully reconnected to ssl://broker1:61616
> Note that the stacktrace occurs for the same reason as AMQ-3085, but all the extra work attempting to connect to invalid uris is wasteful. Also, the client has no need for the query string parameters of the server uris.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (AMQ-3124) Failover transport client gets
corrupted connectedBrokers data
Posted by "Gary Tully (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gary Tully reassigned AMQ-3124:
-------------------------------
Assignee: Gary Tully
> Failover transport client gets corrupted connectedBrokers data
> ---------------------------------------------------------------
>
> Key: AMQ-3124
> URL: https://issues.apache.org/jira/browse/AMQ-3124
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.4.2
> Reporter: Adam Sussman
> Assignee: Gary Tully
> Attachments: amq-3124.patch
>
>
> When clients use the Failover transport, the broker will deliver a list of its own uri and also brokers it peers with to the client. This happens on initial connection and, if configured, as brokers come in and out of the cluster.
> The problem is that the entire URI is given, including query string information. If the query string contains commas in it then the Failover client breaks it up into unusable client uris and will attempt to connect to them. Also, in 5.4.2, this leads to the same failure that occurs in AMQ-3085.
> Also, there doesn't seem to be a point in the client trying to use the same query string parameters that the server is using.
> Attached patch strips the query string before sending uris to the client.
> Example:
> Broker1:
> <transportConnectors>
> <transportConnector name="openwire+ssl" uri="ssl://0.0.0.0:61616?needClientAuth=true&enabledCipherSuites=SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA" />
> </transportConnectors>
> With a client connecting to: failover:(ssl://broker1:61616), you will see (extra debugging added by me):
> [DEBUG] FailoverTransport - Failover add: u[0] is: ssl://broker1:61616
> [DEBUG] FailoverTransport - Reconnect was triggered but transport is not started yet. Wait for start to connect the transport.
> [DEBUG] FailoverTransport - Started.
> [DEBUG] FailoverTransport - Waking up reconnect task
> [DEBUG] FailoverTransport - urlList connectionList:[ssl://broker1:61616]
> [DEBUG] FailoverTransport - Attempting connect to: ssl://broker1:61616
> [DEBUG] FailoverTransport - Failover add: u[0] is: TLS_RSA_WITH_AES_256_CBC_SHA
> [DEBUG] FailoverTransport - Failover add: u[1] is: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
> [DEBUG] FailoverTransport - Failover add: u[2] is: TLS_RSA_WITH_AES_128_CBC_SHA
> [DEBUG] FailoverTransport - Failover add: u[3] is: TLS_DHE_RSA_WITH_AES_128_CBC_SHA
> [DEBUG] FailoverTransport - Failover add: u[4] is: ssl://broker1:61616?needClientAuth=true&enabledCipherSuites=SSL_RSA_WITH_RC4_128_SHA
> [DEBUG] FailoverTransport - Failover add: u[5] is: TLS_DHE_DSS_WITH_AES_128_CBC_SHA
> [WARN] FailoverTransport - Transport (broker1/10.73.76.102:61616) failed to ssl://broker1:61616 , attempting to automatically reconnect due to: java.io.IOException: Unexpected error occured
> [DEBUG] FailoverTransport - Transport failed with the following exception: <java.io.IOException: Unexpected error occured>java.io.IOException: Unexpected error occured
> at org.apache.activemq.transport.failover.FailoverTransport.add(FailoverTransport.java:614)
> at org.apache.activemq.transport.failover.FailoverTransport.updateURIs(FailoverTransport.java:1049)
> at org.apache.activemq.transport.failover.FailoverTransport.processNewTransports(FailoverTransport.java:285)
> at org.apache.activemq.transport.failover.FailoverTransport.handleConnectionControl(FailoverTransport.java:265)
> at org.apache.activemq.transport.failover.FailoverTransport$3.onCommand(FailoverTransport.java:177)
> [DEBUG] FailoverTransport - urlList connectionList:[TLS_RSA_WITH_AES_256_CBC_SHA, ssl://broker1:61616]
> [DEBUG] FailoverTransport - Attempting connect to: TLS_RSA_WITH_AES_256_CBC_SHA
> [DEBUG] FailoverTransport - Connect fail to: TLS_RSA_WITH_AES_256_CBC_SHA, reason: java.io.IOException: Transport not scheme specified: [TLS_RSA_WITH_AES_256_CBC_SHA]
> [DEBUG] FailoverTransport - Attempting connect to: ssl://broker1:61616
> [DEBUG] FailoverTransport - Connection established
> [INFO] FailoverTransport - Successfully reconnected to ssl://broker1:61616
> Note that the stacktrace occurs for the same reason as AMQ-3085, but all the extra work attempting to connect to invalid uris is wasteful. Also, the client has no need for the query string parameters of the server uris.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-3124) Failover transport client gets corrupted
connectedBrokers data
Posted by "Adam Sussman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adam Sussman updated AMQ-3124:
------------------------------
Attachment: amq-3124.patch
Proposed patch. Strips query string from uris.
> Failover transport client gets corrupted connectedBrokers data
> ---------------------------------------------------------------
>
> Key: AMQ-3124
> URL: https://issues.apache.org/jira/browse/AMQ-3124
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.4.2
> Reporter: Adam Sussman
> Attachments: amq-3124.patch
>
>
> When clients use the Failover transport, the broker will deliver a list of brokers it peers with to the client. This happens on initial connection and, if configured, as brokers come in and out of the cluster.
> The problem is that the entire URI is given, including query string information. If the query string contains commas in it then the Failover client breaks it up into unusable client uris and will attempt to connect to them. Also, in 5.4.2, this leads to the same failure that occurs in AMQ-3085.
> Also, there doesn't seem to be a point in the client trying to use the same query string parameters that the server is using.
> Attached patch strips the query string before sending uris to the client.
> Example:
> Broker1:
> <transportConnectors>
> <transportConnector name="openwire+ssl" uri="ssl://0.0.0.0:61616?needClientAuth=true&enabledCipherSuites=SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA" />
> </transportConnectors>
> Broker2:
> <networkConnectors>
> <networkConnector name="core1" uri="static:(ssl://broker1:61616)" duplex="true" />
> </networkConnectors>
> <transportConnectors>
> <transportConnector name="openwire+ssl" uri="ssl://0.0.0.0:61616?needClientAuth=true" />
> </transportConnectors>
> With a client connecting to: failover:(ssl://broker2:61616), you will see (extra debugging added by me):
> [DEBUG] FailoverTransport - Failover add: u[0] is: ssl://broker2:61616
> [DEBUG] FailoverTransport - Reconnect was triggered but transport is not started yet. Wait for start to connect the transport.
> [DEBUG] FailoverTransport - Started.
> [DEBUG] FailoverTransport - Waking up reconnect task
> [DEBUG] FailoverTransport - urlList connectionList:[ssl://broker2:61616]
> [DEBUG] FailoverTransport - Attempting connect to: ssl://broker2:61616
> [DEBUG] FailoverTransport - Failover add: u[0] is: TLS_RSA_WITH_AES_256_CBC_SHA
> [DEBUG] FailoverTransport - Failover add: u[1] is: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
> [DEBUG] FailoverTransport - Failover add: u[2] is: TLS_RSA_WITH_AES_128_CBC_SHA
> [DEBUG] FailoverTransport - Failover add: u[3] is: TLS_DHE_RSA_WITH_AES_128_CBC_SHA
> [DEBUG] FailoverTransport - Failover add: u[4] is: ssl://broker2:61616?needClientAuth=true&enabledCipherSuites=SSL_RSA_WITH_RC4_128_SHA
> [DEBUG] FailoverTransport - Failover add: u[5] is: TLS_DHE_DSS_WITH_AES_128_CBC_SHA
> [DEBUG] FailoverTransport - Failover add: u[6] is: ssl://broker1:61616?needClientAuth=true
> [WARN] FailoverTransport - Transport (broker2/10.73.76.102:61616) failed to ssl://broker2:61616 , attempting to automatically reconnect due to: java.io.IOException: Unexpected error occured
> [DEBUG] FailoverTransport - Transport failed with the following exception: <java.io.IOException: Unexpected error occured>java.io.IOException: Unexpected error occured
> at org.apache.activemq.transport.failover.FailoverTransport.add(FailoverTransport.java:614)
> at org.apache.activemq.transport.failover.FailoverTransport.updateURIs(FailoverTransport.java:1049)
> at org.apache.activemq.transport.failover.FailoverTransport.processNewTransports(FailoverTransport.java:285)
> at org.apache.activemq.transport.failover.FailoverTransport.handleConnectionControl(FailoverTransport.java:265)
> at org.apache.activemq.transport.failover.FailoverTransport$3.onCommand(FailoverTransport.java:177)
> [DEBUG] FailoverTransport - urlList connectionList:[TLS_RSA_WITH_AES_256_CBC_SHA, ssl://broker2:61616]
> [DEBUG] FailoverTransport - Attempting connect to: TLS_RSA_WITH_AES_256_CBC_SHA
> [DEBUG] FailoverTransport - Connect fail to: TLS_RSA_WITH_AES_256_CBC_SHA, reason: java.io.IOException: Transport not scheme specified: [TLS_RSA_WITH_AES_256_CBC_SHA]
> [DEBUG] FailoverTransport - Attempting connect to: ssl://broker2:61616
> [DEBUG] FailoverTransport - Connection established
> [INFO] FailoverTransport - Successfully reconnected to ssl://broker2:61616
> Note that the stacktrace occurs for the same reason as AMQ-3085, but all the extra work attempting to connect to invalid uris is wasteful. Also, the client has no need for the query string parameters of the server uris.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.