ActiveMQ 5.x reliability and ActiveMQ Artemis questions

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

ActiveMQ 5.x reliability and ActiveMQ Artemis questions

Hello everyone,

We are started to investigate how our current messaging system configuration
is fault-tolerant and highly available and we also investigating how we may
increase its throughput.

Currently, we use Apache ActiveMQ 5.14.3 in a Master/Slave configuration
using JDBC Master Slave with a shared database. We use MySQL database on AWS
RDS and we consider it redundant. We use massages persistence in order to
exclude any messages loss.

Fault Tolerance/High Availability
Analyzing the documentation [1], [2], [3], [4] we may say that in order to
achieve fault-tolerant configuration we have the following options:
1. Shared File System Master Slave
2. JDBC Master Slave
3. Replicated LevelDB Store

As we currently use JDBC Master Slave configuration here we have the
following questions:
Q1. Does this configuration protect us from split-brain [c2]?
Q2. Does this configuration protect us from messages loss [c2]?
Q3. Do we understand correctly that Replicated LevelDB Store option should
not be used [c1], [4] and such option is not available for KahaDB? So, in
fact, we have just 2 options in order to achieve fault-tolerant

As is mentioning in the documentation [3], JDBC is slow and this is a fact
we should consider. Now we started to investigate options to increase
throughput of the messaging system and according to our 'no messages loss'
requirement we may use here the following option:
1. Shared File System Master Slave
2. Network of Brokers
3. Tunning configuration

It seems that we should measure performance using JDBC and NFS or GlusterFS
to see the difference in the performance. In case of Network of Brokers we,
for example, may create four pairs of Master/Slaves and then use two of them
for producers and two for consumers or distribute them in a different way.
We also should consider messages order in such case. For configuration
tunning [5], [6] we should review our configuration.
Q4. The question here maybe if we are looking in the right direction

We also considering to change our messaging system if it will not fit our
needs, but preferably is to remain on ActiveMQ. In the process of
researching, we saw some mailing-list discussion [7], [8], [9], [10], [11]
about Apache ActiveMQ Artemis. Sorry for boring you with such question after
reading all of them.
Q5. Just want to confirm that we understand direction correctly and Artemis
have a chance to become next step in ActiveMQ 5.x development and that
currently more development work is done on it [12], [13], [14], [15], [16],

Thank you!


[1] -
[2] -
[3] -
[4] -
[5] -
[6] -

Mailing lists:
[7] -
[8] -
[9] -
[10] -
[11] -

[12] -
[13] -
[14] -
[15] -
[16] -
[17] -

[c1] -
The LevelDB store has been deprecated and is no longer supported or
recommended for use. The recommended store is KahaDB
[c2] -
Apache ActiveMQ passed testing when a Broker was fully shutdown (planned or
unplanned). However, when encountering a temporary network interruption, it
created a situation where there was message duplication and a potential for
lost messages. Similarly, when using the “more reliable” JDBC as the
persistence store, a separate unrelated issue resulted in a concern around
lost messages. IBM MQ passed all testing without message duplication or
potential for lost messages.

Sent from: