activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raul Kripalani <>
Subject Re: Offline message producers
Date Mon, 25 Aug 2014 18:20:17 GMT

If you model your scenario using the failover solution you described (i.e.
clients connect to the central broker, and if that fails, it bootstrap
their embedded broker through a VM Connection Factory), you need to design
a procedure for the "failback".

In other words, how do you detect that the connection to the central broker
is now restored? How should the client behave when the connectivity is
restored but messages are still queued in the embedded broker? Should we
force a "push" to the central broker and in the meantime make the client
wait before it pushes any new messages?

I don't think that's the right solution because it puts too much overhead
on you as the developer.

In contrast, if all clients speak locally to their own embedded brokers,
and those brokers in turn hold a network connection to the central broker
(kinda like a hub-and-spoke, where the spokes are the embedded brokers),
you can have AMQ handle all the failover and failback/recovery while
preserving message order.

In order to avoid the extra thread overhead, you can experiment with
the optimizedDispatch destination policy option, which, IIRC, in theory
makes AMQ piggyback on the thread handling the incoming message to deliver
it to the consumer's connection (i.e. in this case the implicit consumer is
the message forwarding bridge that AMQ creates to push messages out to the
networked broker).


*Raúl Kripalani*
Apache Camel PMC Member & Committer | Enterprise Architect, Open Source
Integration specialist | | twitter: @raulvk

On Mon, Aug 25, 2014 at 3:45 PM, tonowie <>

> Hi,
> I am considering ActiveMQ for data delivery in a setup where client and
> server exchange data. I would like to place ActiveMQ between the client and
> server. The requirements are as follows
> 1) both clients and servers need to send and receive data
> 2) client needs to be able to produce messages even when not connected to
> the network
> 3) messages sent by one side need to be received by the other side in order
> (considering priorities)
> 4) messages should not get lost (system is able to recover from small
> message loss but it is better to avoid it)
> Now first thing that comes to mind is that every client and server will
> have
> queue which it will consume from and when it will want to send message to
> someone it will simply place message to the queue consumed by the
> recipient.
> There would be single ActiveMQ server (with persistence enabled) running
> and
> everyone would connect to it. This addresses everything except for second
> requirement.
> To address the requirement no2 I am thinking about adding embedded
> persistent broker (vm:// protocol) on the client side. Considered it to be
> only failover but then I am not sure about order of messages at the time
> when client gets online (queued in broker vs. new ones)
> Now the questions are:
> * is this a proper way to do it?
> * if it is the way to go then what is the best way to get data from the vm
> broker to the server? Should I configure it as a network of brokers? Would
> that be stable enough? I would like to avoid having thread to copy data
> between the brokers
> thanks
> Tono
> --
> View this message in context:
> Sent from the ActiveMQ - User mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message