Note: Using qpid-java as component (but referring to the latest pacakged qpid-jms-client 0.3.0). See more information in a linked JIRA "When client (re)connects using ReconnectBackOff set to false/0/off - this value is always ignored and default value of 2 of reconnectBackOffMultiplier is used. Also failover.reconnectBackOffMultiplier is ignored when reconnectBackOff is set to true."
( Copy of comment from: https://issues.jboss.org/browse/ENTMQCL-13?focusedCommentId=13099846&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13099846 ) I believe this is because the URI being used isnt in the documented format (e.g detailed at: http://qpid.apache.org/releases/qpid-jms-0.4.0/docs/index.html#failover-configuration-options). The documented format looks like: {noformat} failover:(brokerURI1[,brokerURI2])?<failover.options>&<failover.nested.options> {noformat} whereas the format being used here is: {noformat} failover:amqp://localhost:5672?<jms.options>&<failover.options>. {noformat} In the above case it isnt distinguishable [without the documented use of parethesis] that the stuff after the ? isn't part of the broker URI, and so it had no effect on the failover layer but was instead treated as part of the broker uri. The 'failover.' options were presumably then not collected for use by the JMS/transport layers when given the URI because they dont match the relevant prefix those layers use. Adding the parethesis as documented should get things going.
Michal Toth <mtoth> updated the status of jira ENTMQCL-13 to Closed
Closing BZ to match the JIRA, Michal confirmed things work with the URI update.