activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Timothy Bish <>
Subject Re: Datacenter failover and randomizing connections
Date Thu, 24 Sep 2015 21:45:39 GMT
On 09/24/2015 05:31 PM, Basmajian, Raffi wrote:
> Hello,
> We're trying to determine the correct client failover URL for this scenario:
> 2 brokers in New York (master/slave)
> 2 brokers in Chicago     (master/slave)
> Client connections from NY are prioritized (and randomized) to NY; failover to Chicago
if no local brokers available.
> Client connections from Chicago are prioritized (and randomized) to Chicago; failover
to NY if no local brokers available.
> Topology is full graph/NoB; one network hop separates any two brokers.
> What we've tried so far (assumes clients located in NY)
> Randomizes connections across local and remote brokers (not good)
> failover:(tcp://ny1,tcp://ny2,tcp://chi1,tcp://chi2)
> Always picks first local broker (not good)
> failover:(tcp://ny1:61600,tcp://ny2,tcp://chi1,tcp://chi2)?randomize=false
> No different than previous; always selects first broker
> failover:(tcp://ny1,tcp://ny2,tcp://chi1,tcp://chi2)?randomize=false&priorityBackup=true
> We haven't tried this yet, but is it possible to nest failover transports? If so, technically
this should select the first group, NY brokers, randomizing connections automatically within
that cluster, then moving to Chicago and doing the same if no brokers in NY are available.
> failover:( failover:(tcp://ny1,tcp://ny2), failover:(tcp://chi1,tcp://chi2))?randomize=false&priorityBackup=true
> We're exploring DNS and F5 options as well, but we want to leverage the software as much
as possible before configuring infrastructure.
> Thank you
> Raffi
> This e-mail transmission may contain information that is proprietary, privileged and/or
confidential and is intended exclusively for the person(s) to whom it is addressed. Any use,
copying, retention or disclosure by any person other than the intended recipient or the intended
recipient's designees is strictly prohibited. If you are not the intended recipient or their
designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds
may, at its sole discretion, monitor, review, retain and/or disclose the content of all email
One option that you haven't yet tried given the above examples is

Refer to the failover transport page:

Tim Bish
Sr Software Engineer | RedHat Inc. | 
twitter: @tabish121

View raw message