"Network of Brokers" and persistence

[Steve Cohen <sc...@javactivity.org>]

I am in the phase of imagining what using ActiveMQ to design a wrapper 
around a legacy process would look like, and reading the book, which I 
have bought.  I should say that I am impressed so far with ActiveMQ and 
the mapping of what it does with what I am trying to do seems very good.

I am trying to understand the relation of persistence to the "network of 
brokers" concept.  In a single standalone broker deployment, it's 
simple.  You either enable persistence of one flavor or another, or you 
don't.

But what does this look like in the "network of brokers" concept?  There 
is something appealing in this model to my situation, of deploying a 
server-side application in which each instance has an instance of the 
broker embedded within it, but what are the consequences in terms of 
persistence?  Would there just be one persistent store, with a suitable 
backup arrangement?

Please help me untangle the consequences of these two concepts, which 
are starting to boggle my mind a bit.

Re: "Network of Brokers" and persistence

[Gary Tully <ga...@gmail.com>]

networks of brokers in activemq are store and forward. So a persistent
message will only exist on one broker at a time.
If can start on the embedded broker and get forward to a networked
broker if there is demand, In which case it will be removed/consumed
from the embedded broker and sent to the target broker by the network
connector. So from a network of brokers perspective, persistence is
still handled individually by each broker.

On 15 November 2010 14:36, Steve Cohen <sc...@javactivity.org> wrote:
> I am in the phase of imagining what using ActiveMQ to design a wrapper
> around a legacy process would look like, and reading the book, which I have
> bought.  I should say that I am impressed so far with ActiveMQ and the
> mapping of what it does with what I am trying to do seems very good.
>
> I am trying to understand the relation of persistence to the "network of
> brokers" concept.  In a single standalone broker deployment, it's simple.
>  You either enable persistence of one flavor or another, or you don't.
>
> But what does this look like in the "network of brokers" concept?  There is
> something appealing in this model to my situation, of deploying a
> server-side application in which each instance has an instance of the broker
> embedded within it, but what are the consequences in terms of persistence?
>  Would there just be one persistent store, with a suitable backup
> arrangement?
>
> Please help me untangle the consequences of these two concepts, which are
> starting to boggle my mind a bit.
>
>



-- 
http://blog.garytully.com
http://fusesource.com

Re: "Network of Brokers" and persistence

[NerdyNick <ne...@gmail.com>]

I have however also notice that persistent doesn't appear to handle
failover well when in a network of brokers setup. For instance say you
have 3 brokers with a consumer attached to each. All connected in a
persistent style. If broker 1 goes down and the consumer switches over
to broker 2. Any messages passed during that period are lost, but I
can understand that, but what goes weird is that when broker 1 comes
back online. It still builds up messages to be delivered to the
consumer that use to be attached to it.

On Mon, Nov 15, 2010 at 7:37 AM, Johan Edstrom <se...@gmail.com> wrote:
> If you think of persistence in the same way you would a POP3 store,
> i.e the object of the persistence store is more to provide reliability in that
>
> 1: Write incoming message to disk,
> 2: Maintain a journal of actions taken to the message
> 3: Remove the message from the store once consumed.
>
> So the persistence would be invoked on every broker that participated in a message exchange
> to ensure consistency across the brokers. There is no master storage nor is a message 'replicated' to all nodes.
>
> /je
> On Nov 15, 2010, at 7:36 AM, Steve Cohen wrote:
>
>> I am in the phase of imagining what using ActiveMQ to design a wrapper around a legacy process would look like, and reading the book, which I have bought.  I should say that I am impressed so far with ActiveMQ and the mapping of what it does with what I am trying to do seems very good.
>>
>> I am trying to understand the relation of persistence to the "network of brokers" concept.  In a single standalone broker deployment, it's simple.  You either enable persistence of one flavor or another, or you don't.
>>
>> But what does this look like in the "network of brokers" concept?  There is something appealing in this model to my situation, of deploying a server-side application in which each instance has an instance of the broker embedded within it, but what are the consequences in terms of persistence?  Would there just be one persistent store, with a suitable backup arrangement?
>>
>> Please help me untangle the consequences of these two concepts, which are starting to boggle my mind a bit.
>>
>
>



-- 
Nick Verbeck - NerdyNick
----------------------------------------------------
NerdyNick.com
Coloco.ubuntu-rocks.org

Re: "Network of Brokers" and persistence

[Johan Edstrom <se...@gmail.com>]

If you think of persistence in the same way you would a POP3 store, 
i.e the object of the persistence store is more to provide reliability in that 

1: Write incoming message to disk,
2: Maintain a journal of actions taken to the message
3: Remove the message from the store once consumed.

So the persistence would be invoked on every broker that participated in a message exchange
to ensure consistency across the brokers. There is no master storage nor is a message 'replicated' to all nodes.

/je
On Nov 15, 2010, at 7:36 AM, Steve Cohen wrote:

> I am in the phase of imagining what using ActiveMQ to design a wrapper around a legacy process would look like, and reading the book, which I have bought.  I should say that I am impressed so far with ActiveMQ and the mapping of what it does with what I am trying to do seems very good.
> 
> I am trying to understand the relation of persistence to the "network of brokers" concept.  In a single standalone broker deployment, it's simple.  You either enable persistence of one flavor or another, or you don't.
> 
> But what does this look like in the "network of brokers" concept?  There is something appealing in this model to my situation, of deploying a server-side application in which each instance has an instance of the broker embedded within it, but what are the consequences in terms of persistence?  Would there just be one persistent store, with a suitable backup arrangement?
> 
> Please help me untangle the consequences of these two concepts, which are starting to boggle my mind a bit.
>