CODEWITHSUNDEEP
javaapache-camelenterprise-integration
TheRocinante
TheRocinante

Reputation: 4201

Guaranteed delivery in Camel

I am using Apache Camel with ActiveMQ and wanting to implement guaranteed message delivery.

I have been reading through the Camel in Action book as well as the Apache Camel Developer's Cookbook.

I am hoping someone here can advise me in my approach. I am not asking for code samples.

The way I envisioned the implementation is as follows:

1. Message is received on an endpoint
2. I inspect the message
3. I use the Wiretap pattern to drop it immediately on my "GuaranteedMessages" queue if the message asks for guaranteed delivery
4. I route the message to its proper destination
5. If no exceptions were encountered, I remove the message manually from the "GuaranteedMessages" queue

Sounds easy enough. However, I have been reading about the "Dead Letter Channel" pattern in Camel.

My understanding is using this pattern's implementation implies that instead of automatically dropping each (guaranteed) message to my "GuaranteedMessages" queue, I drop that approach and instead, I set the redelivery options (max attempts, exponential delay, redelivery delay, etc.). Then, I rely on Camel to try redelivering and simply drop it off in the dead letter channel delay if it never goes through.

Then, I would have a separate route that uses this dead letter queue as it's source. Again, it would be the same pattern. If it cannot succeed, send the message back to the dead letter queue.

Does this sound like a realistic implementation for a production system?

If instead, I decide to drop every incoming message (that needs to be guaranteed) on my own "GuaranteeMessage" queue, is it realistic to believe that I can later go and remove that specific message manually from the queue? My understanding is that I would have to manually browse the queue, iterate through any number of messages, and then consume that message manually. I am not sure how scalable such an architecture really is.

Upvotes: 1

Views: 1409

Answers (1)

matt helliwell
matt helliwell

Reputation: 2678

Presumably the final destination is not another ActiveMQ queue, it something that can through exception. Your idea of the wiretap is functionally the same as using the DLQ so you might as well use the Camel functionality, which works fine, to do as much work as possible.

However, two points. Firstly I would use an explicit queue to hold the messages that need retrying, rather than the DLQ, as there is only one DLQ per broker and you don't want anything else unexpected appearing on it.

Secondly if you are just going to take a message from the retry queue and resubmit it, why not just increase the retry count and delay in Camel exception handling? That way your retry queue just has messages that probably require some manual intervention. So when a message is on the retry queue, you manually check/fix whatever the underlying cause is and manually move the message to the input queue.

Upvotes: 1

Related Questions