CODEWITHSUNDEEP
javarabbitmqapache-camelspring-rabbitspring-camel
DevelopperX
DevelopperX

Reputation: 85

Avoid camel from sending messages to queue when RabbitMQ is down

I am fairly new to RabbitMQ and Apache-Camel. Messages are bing picked off an interface (IMAP, etc) and sent to a queue for further processing. I am struggling to find a solution to avoid messages being lost in a scenario when RabbitMQ is down. What would be the best solution to avoid messages being sent to a queue by a camel route?

I use Spring DSL with camel version 2.25.1.

Thanks in advannce.

Upvotes: 0

Views: 968

Answers (2)

Prashant Bhardwaj
Prashant Bhardwaj

Reputation: 176

You can write failed messages on a file. And can have another route to read from file and send to queue. Which you should be able to start on demand (after making sure your jms broker is up and running)

Upvotes: 1

burki
burki

Reputation: 7005

The problem in such integration scenarios is: when the target is down, where can you save the message until the target is up again?

Because you normally have no possibility to save the data, you have no other choice than "pushing it back to the source".

This is normally done with transactional consumption from the source. You consume a message from the source in a transaction. When you can process the message and deliver it to the target, you commit the message on the source transaction. From this point on, the target is responsible for the message.

If you cannot process the message or the target is down, you roll back the transaction so that the source stays responsible for the message.

Like this your integration never becomes responsible for the data. The messages either stay on the source or reach the target.

So, coming back to your question, you don't need to avoid sending a message to a not available broker (how could you know in advance that it is down?), but if the sending fails (for whatever reason), you should make sure that the message is not removed/committed on the source system.

The next step is then to handle retry-scenarios to avoid consuming the same message over and over again while your broker is down. But this is an entire new integration chapter.

After explaining the basic principle, I have to add that in messaging systems, the brokers are the heart of the system and should therefore be highly available (cluster, network of brokers etc). So it is very good to think about the broker-down-scenario, but this should be a very rare edge case.

Upvotes: 2

Related Questions