activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rallavagu <>
Subject Re: ActiveMQ deployment
Date Tue, 01 Dec 2015 19:56:30 GMT
Now, I am getting a clearer picture about the options. Essentially, NOB 
provides load balancing while Master/Slave offers pure failover. In case 
I go with combination where a Master/Slave cluster is configured with 
NOB with other Master/Slave cluster how would the client failover 
configuration would work?

Will a set of consumers always connect a one of the Master/Slave 
cluster? In this case how would load balance work? Thanks.

On 12/1/15 11:32 AM, Basmajian, Raffi wrote:
> NoB forwards messages based on consumer demand, not for achieving failover.
> You can get failover on the client using standalone brokers, just use failover:() protocol
from client.
> Master/Slave is true failover.
> -----Original Message-----
> From: Rallavagu []
> Sent: Tuesday, December 01, 2015 1:06 PM
> To:
> Subject: Re: ActiveMQ deployment [ EXTERNAL ]
> Thanks again Johan. As the failover is configured at the client end how would the configuration
for combined deployment look like?
> I was thinking on the lines of NOB because the messages are forwarded to other broker(s)
thus achieving failover capabilities in case the original broker is failed the duplicate messages
are available on second
> (other) broker(s). Am I off in my assumption?
> On 12/1/15 9:35 AM, Johan Edstrom wrote:
>> You want to combine them, the NOB is for communication but JMS is still store and
forward, i.e if a machine dies, you can have multiple paths, what was in the persistence store
of said machine is still "dead" until the machine is revived, that's where the Master / Slave(s)
come in. They'll jump in and start playing that persistence store.
>> /je
>>> On Nov 30, 2015, at 10:57 PM, Rallavagu <> wrote:
>>> Thanks Johan.
>>> My goal is to achieve high availability (with failover) for producer and consumer
in addition to mitigate a situation of "there is a chance that one broker has producers but
no consumers".
>>> As per the documentation, it sounds like NOB is an option which can offer failover
and scalability. I was wondering if Master/Slave is the only option to achieve high availability
but it appears to me that NOB can offer the same. Wanted to check this with folks here in
this list if there is anything I am missing.
>>> On 11/30/15 9:28 PM, Johan Edstrom wrote:
>>>> What you probably want is a combination of HA and communication.
>>>> HA I.e master and slave(s) (Depending on storage) gives you uptime.
>>>> NOB gives you communication paths and as such scalability and for some value
of it versatility.
>>>> You can also use the two above and combine that with bridges to build small
little scalable clouds that forward like say enterprise email systems.
>>>> You can also go the completely different route and say that in your Enterprise
you only use central brokers for messages between systems of importance, then you use local
broker networks for message patterns, aggregation etc.
>>>> There is no one solution here. If you have more specific questions it might
be easier for people here to help as we might have more associations possible?
>>>> /je
>>>>> On Nov 30, 2015, at 3:25 PM, Rallavagu <> wrote:
>>>>> After spending some time reading, with reference to the following
>>>>> link,
>>>>> What I am trying to figure out is if it is possible to achieve a cluster
with fault tolerance deploying with "Networks of brokers" or should I consider "Master/Slave"
in addition to "Networks of brokers". Not sure how the hybrid deploying works. Any comments
would help. Thanks.
>>>>> On 11/25/15 11:13 AM, Rallavagu wrote:
>>>>>> Any takers on this? Thanks.
>>>>>> On 11/24/15 1:37 PM, Rallavagu wrote:
>>>>>>> All,
>>>>>>> What is the recommended deployment architecture for an enterprise?
>>>>>>> 1. Master/Slave with replicated Level DB
>>>>>>> (
>>>>>>> 2. Network of Brokers for scalability
>>>>>>> 3. Hybrid
>>>>>>> In case of hybrid, is there a reference document that I could
>>>>>>> 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

View raw message