Livraison garantie en Camel

Question

J'utilise Apache Camel avec ActiveMQ et je souhaite mettre en place une livraison garantie des messages. Je lisais le livre Camel in Action ainsi que le livre de recettes du développeur Apache Camel. J'espère que quelqu'un ici pourra me conseiller dans mon approche. Je ne demande pas d'échantillons de code.

La façon dont j'envisagé la mise en œuvre est la suivante:

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 

Cela semble assez facile. Cependant, j'ai lu sur le modèle "Dead Letter Channel" dans Camel. Si je comprends bien, l'implémentation de ce modèle implique qu'au lieu de déposer automatiquement chaque message (garanti) dans ma file d'attente "GuaranteedMessages", j'abandonne cette approche et je règle les options de relivraison (tentatives max, délai exponentiel, délai de relivraison , etc.). Ensuite, je compte sur Camel pour essayer de relancer et je l'abandonne simplement dans le délai de canal de lettre morte s'il ne passe jamais. Ensuite, j'aurais une route séparée qui utilise cette file d'attente de lettres mortes comme source. Encore une fois, ce serait le même modèle. Si cela ne réussit pas, renvoyez le message à la file d'attente des lettres mortes.

Cela ressemble-t-il à une implémentation réaliste pour un système de production? Si à la place, je décide de supprimer chaque message entrant (qui doit être garanti) dans ma propre file d'attente "GuaranteeMessage", est-il réaliste de penser que je pourrai ultérieurement retirer manuellement ce message de la file d'attente? Ma compréhension est que je devrais parcourir manuellement la file d'attente, itérer à travers un certain nombre de messages, puis consommer ce message manuellement. Je ne suis pas sûr à quel point une telle architecture est vraiment évolutive.

Answer 1

Vraisemblablement la destination finale n'est pas une autre file d'attente ActiveMQ, c'est quelque chose qui peut passer par l'exception. Votre idée de l'écoute électronique est fonctionnellement la même que l'utilisation de la DLQ, donc vous pouvez aussi bien utiliser la fonctionnalité Camel, qui fonctionne bien, pour faire le plus de travail possible.

Toutefois, deux points. Tout d'abord, j'utiliserais une file d'attente explicite pour contenir les messages à réessayer, plutôt que le DLQ, car il n'y a qu'un seul DLQ par courtier et vous ne voulez rien d'autre d'inattendu apparaissant dessus. Deuxièmement, si vous voulez juste prendre un message de la file d'attente de nouvelle tentative et le soumettre à nouveau, pourquoi ne pas simplement augmenter le nombre de nouvelles tentatives et retarder la gestion des exceptions Camel? De cette façon, votre file d'attente de tentatives n'a que des messages qui nécessitent probablement une intervention manuelle. Ainsi, lorsqu'un message est dans la file d'attente de nouvelle tentative, vous vérifiez/corrigez manuellement la cause sous-jacente et déplacez manuellement le message dans la file d'attente d'entrée.