activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <>
Subject Re: Shared File System Master Slave
Date Fri, 06 Apr 2018 12:59:18 GMT
The AMQ store is not widely used these days. You'll probably be using the
KahaDB store:

As you said, if there is any content that has not been flushed to disk, it
will be lost when the master goes down. However, unless you've manually
set enableJournalDiskSyncs to false, you're not going to lose any messages
whose receipt has been confirmed by the broker. (Any messages lost will be
messages the broker has not yet confirmed receipt of.)

When the slave broker attempts to become active, it will read the data
files and begin serving clients.

You asked whether subscriptions would be on the new master, and the answer
depends on whether the subscription was durable. If it was a durable
subscription, the subscription information is persisted and the
subscription will be in the same state on the new master, even if the
client doesn't immediately reconnect. If the subscription is not durable,
then it will be recreated when the client reconnects to the new master, so
any messages that were unconsumed at the time the original master went down
and any messages sent before the client reconnects will be lost for that


On Fri, Apr 6, 2018, 1:54 AM norinos <> wrote:

> I am planning to use Shared File System Master Slave.(I use AcitveMQ
> 5.13.1)
> With this system, even though master(#1)'s process goes down due to
> trouble,
> I think that ActiveMQ can be continuously used in slave(#2) process.
> I have a question.
> According to the above documentation, MQ's memory cache periodically
> inserted into the reference store(
> If master(#1) goes down, memory cache cannot insert.
> It seems that the reference sotre index does not match the Data Logs.
> At this time, can #2(New master) start normally ?
> If not, What kind of trouble will occur ?
> For example, Subscribed messages will be subscribe agein.
> --
> Sent from:

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