activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Basmajian, Raffi" <rbasmaj...@ofiglobal.com>
Subject RE: Datacenter failover and randomizing connections
Date Thu, 24 Sep 2015 22:05:43 GMT
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:tabish121@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:tabish121@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.bish@redhat.com | www.redhat.com
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>


--
Tim Bish
Sr Software Engineer | RedHat Inc.
tim.bish@redhat.com | www.redhat.com
twitter: @tabish121
blog: http://timbish.blogspot.com/


Mime
View raw message