OK, So with the following URL, initial connections are randomized amongst "tcp://ny1,tcp://ny2", if neither available, remaining brokers in list are tried. If priority brokers become available again, switch back to those brokers, but randomize the selection when switching back.
failover:(tcp://ny1,tcp://ny2,tcp://chi1,tcp://chi2) randomize=true priorityBackup=true priorityURIs=tcp://ny1,tcp://ny2 Thanks, Tim, very helpful! Best, Raffi -----Original Message----- From: Timothy Bish [mailto:tabish...@gmail.com] Sent: Thursday, September 24, 2015 5:57 PM To: users@activemq.apache.org Subject: Re: Datacenter failover and randomizing connections [ EXTERNAL ] Importance: High On 09/24/2015 05:53 PM, Basmajian, Raffi wrote: > Tim, > > We missed that one! Looks promising, though the only gripe I have with that > approach is duplication of data, creating maintenance overhead and higher > likelihood of misconfigurations. > > I assume the nested option I suggested is not supported? Nope > > Raffi > > -----Original Message----- > From: Timothy Bish [mailto:tabish...@gmail.com] > Sent: Thursday, September 24, 2015 5:46 PM > To: users@activemq.apache.org > Subject: Re: Datacenter failover and randomizing connections [ > EXTERNAL ] > Importance: High > > 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= >> f >> alse >> >> No different than previous; always selects first broker >> failover:(tcp://ny1,tcp://ny2,tcp://chi1,tcp://chi2)?randomize=false& >> p >> riorityBackup=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 communications. >> > One option that you haven't yet tried given the above examples is > priorityURIs > > Refer to the failover transport page: > http://activemq.apache.org/failover-transport-reference.html > > -- > Tim Bish > Sr Software Engineer | RedHat Inc. > tim.b...@redhat.com | www.redhat.com > twitter: @tabish121 > blog: http://timbish.blogspot.com/ > > -- Tim Bish Sr Software Engineer | RedHat Inc. tim.b...@redhat.com | www.redhat.com twitter: @tabish121 blog: http://timbish.blogspot.com/
