0

I have a master/slave AMQ broker setup for JMS messaging. I have two servers that I would like to setup as a master/slave durable consumers using Apache Camel. We've been achieving this by having both servers attempt to connect with the same client ID. One node handles all of the work but if it goes down the other node connects and picks right back up on the work. This has been working fine for having a single consumer at a time but it makes noise in disconnected server's log files with the message 

 ERROR org.apache.camel.component.jms.DefaultJmsMessageListenerContainer] 
(Camel (spring-context) thread #0 - JmsConsumer[global.topic.event]) Could 
not refresh JMS Connection for destination 'global.topic.event' - retrying 
using FixedBackOff{interval=5000, currentAttempts=12, 
maxAttempts=unlimited}. Cause: Broker: broker - Client: client already 
connected from tcp://xxx.xx.xx.xxx:xxxx

Is there a proper way to get the functionality that I'm looking to achieve? I was considering having the slave server ping the master to coordinate which one is connected but I'd like to keep the implementation as simple as possible.

Jaocb Zielny
  • 13
  • 5
  • Why not move to ActiveMQ Artemis which implements JMS 2.0 so you can have shared durable subscriptions? This would allow both consumers to process messages and spread the load rather than having an master/slave consumer where one consumer is completely idle most of the time. – Justin Bertram Aug 15 '18 at 15:02
  • Since we are consuming from a topic which is also consumed by other systems I believe that would result in both of these consumers processing all messages. Ideally each message would only be processed by one of these two consumers. – Jaocb Zielny Aug 15 '18 at 16:49
  • JMS 2.0 (which isn't supported in ActiveMQ 5.x) added *shared* durable subscriptions which allows multiple clients to connect to the same durable subscription and *share* the messages. Therefore, each message in the subscription would only go to a single consumer. – Justin Bertram Aug 15 '18 at 17:59

1 Answers1

0

Convert your usage of topics on the consumer side to Virtual Topics. Virtual Topics allow you to continue to have existing message flows produce and consume from the topic, but also have consumers listen on specially named queues.

Once you are consuming from a queue, you can implement all the consumer patterns-- exclusive consumer (which allows that hot-standby backup consumer), message groups, parallel consumers, etc.

Matt Pavlovich
  • 4,087
  • 1
  • 9
  • 17
  • It's worth noting that Virtual Topics are proprietary to ActiveMQ which will impact the portability of the application. – Justin Bertram Aug 16 '18 at 14:53
  • @Justin, I disagree it impacts the portability of the application. The internal-to-ActiveMQ configuration is specific to ActiveMQ, but from a client application perspective it is accomplished with standard JMS-APIs. The behavior is 100% portable to IBM MQ and readily recreated with most other JMS brokers. – Matt Pavlovich Aug 17 '18 at 17:27
  • My point here is simply that anything that isn't codified in a specification is subject to portability issues. As I understand it, ActiveMQ Virtual Topics were created to deal with some of the shortcomings of JMS durable subscriptions. This was implemented (in part) using special naming conventions from the client-side which are not portable. However, JMS 2 solves this problem with shared subscriptions which are portable. I'm not saying it's a huge issue, but it's something worth noting especially where there are good, standardized alternatives at this point. – Justin Bertram Aug 17 '18 at 18:59