activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <>
Subject Re: Network of brokers as a cluster
Date Thu, 06 Nov 2014 21:25:11 GMT
As far as I know, this behavior would happen with simple topics and simple
queues just as much as with virtual topics; this is a result of ActiveMQ's
fundamental architecture, not something specific to virtual topics.  The
architecture of ActiveMQ ensures that any broker only knows about its own
messages and not those held by any other broker.  This allows for
complicated, flexible networks of brokers that would be difficult or
impossible otherwise, but because brokers don't have access to messages
elsewhere in the network, they can't replay messages if a broker goes down.

If you want reliability of message delivery in the face of broker failure
(instead of only reliability of the routing infrastructure but temporary
unavailability of messages), you should use the master/slave paradigm; it
was developed to handle exactly the situation you're looking at.

Also, you can have a durable subscription on a simple topic, which will
allow the consumer to get all messages (including all messages sent while
the consumer is disconnected), so I'm not sure why you're saying that a
non-durable topic subscription is your best remaining option; I'd think
that a durable subscription would still be preferable to a non-durable one
for the use case you described, whether or not you use a master/slave
broker pair to ensure that you can access all messages even when one broker
goes down.


On Thu, Nov 6, 2014 at 1:07 PM, jeremy11 <> wrote:

> Hi,
> I guess this is a real problem with networks of broker and virtual topics,
> I
> thought it could solve the problem of messages getting stuck when one of
> the
> brokers go down.
> I guess I will go on a simple topic and if my consumer goes down and
> reconnects he will only gets new messages (not  durable).
> thanks for the answers
> --
> View this message in context:
> Sent from the ActiveMQ - User mailing list archive at

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