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 configuration. Throughput 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 Future 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], [17]. Thank you! Slava. Documentation: [1] - http://activemq.apache.org/clustering.html [2] - http://activemq.apache.org/shared-file-system-master-slave.html [3] - http://activemq.apache.org/jdbc-master-slave.html [4] - http://activemq.apache.org/replicated-leveldb-store.html [5] - http://activemq.apache.org/performance-tuning.html [6] - http://activemq.apache.org/performance.html Mailing lists: [7] - http://activemq.2283324.n4.nabble.com/DISCUSS-LevelDB-deprecation-td4719227.html [8] - http://activemq.2283324.n4.nabble.com/Switch-to-Artemis-from-ActiveMQ-v5-14-4-td4727014.html [9] - http://activemq.2283324.n4.nabble.com/ActiveMQ-vs-Apache-artemis-td4730906.html [10] - http://activemq.2283324.n4.nabble.com/VOTE-ActiveMQ-Artemis-becomes-ActiveMQ-6-td4733392.html [11] - http://activemq.2283324.n4.nabble.com/DISCUSS-Confusion-surrounding-the-ActiveMQ-project-roadmap-td4732935.html Development: [12] - https://github.com/apache/activemq/releases [13] - https://github.com/apache/activemq/graphs/commit-activity [14] - https://issues.apache.org/jira/projects/AMQ/issues/AMQ-6977?filter=allopenissues [15] - https://github.com/apache/activemq-artemis/releases [16] - https://github.com/apache/activemq-artemis/graphs/commit-activity [17] - https://issues.apache.org/jira/projects/ARTEMIS/issues/ARTEMIS-1975?filter=allopenissues Citations: [c1] - http://activemq.apache.org/replicated-leveldb-store.html -- The LevelDB store has been deprecated and is no longer supported or recommended for use. The recommended store is KahaDB -- [c2] - https://webspherecompetition.wordpress.com/2015/08/12/apache-activemq-and-ibm-mq-high-availability-and-administrative-analysis/ -- 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: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
