activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rallavagu <rallav...@gmail.com>
Subject Re: NoB and Load Balancing
Date Fri, 11 Dec 2015 15:22:31 GMT
Tim,

Thanks for chiming in. As I am testing the configuration to determine 
deployment architecture and configuration, there are currently no 
clients available that are using this topology. I am trying to 
understand the behavior so can make right choices for deployment. Having 
said that, I was using the consumer supplied in the "examples" directory 
of distribution download.

This is what I have used for testing,

ant consumer 
-Durl=failover:'(tcp://activemq3.localtest.com:61616)?randomize=false&priorityBackup=true'

-Dtopic=false -Dsubject=foo.bar

Here is the transportConnector config,

<transportConnector name="openwire" 
uri="tcp://0.0.0.0:61616?maximumConnections=1000&amp;wireFormat.maxFrameSize=104857600"

updateClusterClients="true" rebalanceClusterClients="true" 
updateClusterClientsOnRemove="true" />

Thanks

On 12/11/15 6:50 AM, Tim Bain wrote:
> I don't think priorityBackup=true is what you want; in fact, the note in
> http://activemq.apache.org/failover-transport-reference.html on
> rebalanceClusterClients explicitly points out that the two features
> interfere with each other.
>
> Do you have randomize=true on your client URI?  If not, I think you should.
>
> Do you have a minimal test case (broker configs, client code, etc.) that
> you could package up so someone could step through the code in a debugger
> and see why it's doing what it's doing?  Because it seems strange that it
> would be failing for you when there's a unit test (
> https://github.com/apache/activemq/blob/15affd0755deeebcdc670039ec1d19fefe0d8c65/activemq-unit-tests/src/test/java/org/apache/activemq/transport/failover/TwoBrokerFailoverClusterTest.java)
> that should be proving that exactly this scenario works.
>
> Tim
>
> On Thu, Dec 10, 2015 at 11:44 AM, Rallavagu <rallavagu@gmail.com> wrote:
>
>> Adding "priorityBackup=true" on client seem to work as in falling back to
>> original node once it is back to service. Thanks.
>>
>> On 12/9/15 10:30 PM, Tim Bain wrote:
>>
>>> Also, did you see the "Update" paragraph at the bottom of
>>>
>>> http://bsnyderblog.blogspot.com/2010/10/new-features-in-activemq-54-automatic.html
>>> ?
>>> Based on that paragraph, I think you'd need to set
>>> updateClusterClientsOnRemove="true" to get the behavior you're looking for
>>> (clients reconnecting when a broker comes back up).  Without that, I
>>> believe you'll only get updates when a **new** broker is started, not when
>>>
>>> one is simply restarted.
>>>
>>> Tim
>>>
>>> On Wed, Dec 9, 2015 at 11:26 PM, Tim Bain <tbain@alumni.duke.edu> wrote:
>>>
>>> Are you saying that you're using the priorityBackup=true option, or not?
>>>> That wasn't clear (to me) from what you wrote.
>>>>
>>>> Tim
>>>>
>>>> On Wed, Dec 9, 2015 at 7:31 PM, Rallavagu <rallavagu@gmail.com> wrote:
>>>>
>>>> If you are referring "priorityBackup=true" then I have only one URL with
>>>>> master/slave and NoB and expect the "updateClusterClients" to work. One
>>>>> more item that I have noticed is that, when two clients are connected
to
>>>>> one of the clusters, when the third client is attempting to connect to
>>>>> the
>>>>> same cluster, it is actually forwarded to connect to other cluster
>>>>> (which
>>>>> has no clients at that time).
>>>>>
>>>>>
>>>>> On 12/9/15 6:21 PM, Basmajian, Raffi wrote:
>>>>>
>>>>> I don't believe client failback would work with those settings alone,
>>>>>> Read section titled "More information" here
>>>>>> http://activemq.apache.org/failover-transport-reference.html
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Rallavagu [mailto:rallavagu@gmail.com]
>>>>>> Sent: Wednesday, December 09, 2015 8:40 PM
>>>>>> To: users@activemq.apache.org
>>>>>> Subject: Re: NoB and Load Balancing [ EXTERNAL ]
>>>>>>
>>>>>> I am using the example that are shipped with ActiveMQ. Here is the
>>>>>> example,
>>>>>>
>>>>>> /opt/activemq/apache-ant-1.9.6/bin/ant consumer -Durl=failover:'(tcp://
>>>>>> activemq2.localtest.net:61616)' -Dtopic=false -Dsubject=foo.bar
>>>>>>
>>>>>> On 12/9/15 4:19 PM, Basmajian, Raffi wrote:
>>>>>>
>>>>>> Show the client-side configuration you're using.
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Rallavagu [mailto:rallavagu@gmail.com]
>>>>>>> Sent: Wednesday, December 09, 2015 7:04 PM
>>>>>>> To: users@activemq.apache.org
>>>>>>> Subject: NoB and Load Balancing [ EXTERNAL ]
>>>>>>>
>>>>>>> ActiveMQ 5.12.1
>>>>>>>
>>>>>>> Setup Network of Brokers between two clusters of Master/Slave
brokers.
>>>>>>> With reference to following links,
>>>>>>>
>>>>>>> http://bsnyderblog.blogspot.com/2010/10/new-features-in-activemq-54-au
>>>>>>> tomatic.html
>>>>>>> http://activemq.apache.org/failover-transport-reference.html
>>>>>>>
>>>>>>> Configured "updateClusterClients" and "rebalanceClusterClients"
to
>>>>>>> achieve load balancing. Used a test case as below.
>>>>>>>
>>>>>>> 1. connect client 1 to cluster 1
>>>>>>> 2. connect client 2 to cluster 2
>>>>>>> 3. shutdown cluster 1. Now, client 1 is automatically connected
to
>>>>>>> cluster 2.
>>>>>>> 4. started cluster 1 back.
>>>>>>>
>>>>>>> Was expecting client 1 to re-connect to cluster 1 and balance
the
>>>>>>> load.
>>>>>>> But, I do not see that happening. Is this the right expectation?
Also,
>>>>>>> I have noticed that some times if two clients are connecting
to one
>>>>>>> of the
>>>>>>> clusters, they are automatically re-connected to other cluster
which
>>>>>>> is a
>>>>>>> desirable behavior. Essentially, Wondering if I can rely one
those
>>>>>>> configuration parameters for load balancing. Thanks.
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>

Mime
View raw message