Spring Design JMS Question: Découplage du traitement des messages

Question

J'utilise un écouteur de message pour traiter certains messages de MQ basé sur DefaultMessageListenerContainer de Spring. Après avoir reçu un message, je dois effectuer un appel de service Web (WS). Cependant, je ne veux pas faire cela dans la méthode onMessage car cela bloquerait la méthode onMessage jusqu'à ce que l'invocation de WS réussisse, ce qui introduit une latence dans la suppression de la file d'attente des messages de la file d'attente. Comment puis-je dissocier l'appel du service Web en l'appelant en dehors de la méthode onMesage ou sans affecter la suppression de la file d'attente des messages?

Merci,

Answer 1

Je pense que vous pourriez effectivement vouloir appeler le service Web de votre onMessage. Pourquoi voulez-vous supprimer rapidement les messages, puis retarder le traitement ultérieur? Si vous faites ce que vous dites, vous devrez probablement introduire un autre niveau de mise en file d'attente, ou une sorte de collection temporaire, qui est redondante. Le point de la file d'attente est de contenir des messages, et votre écouteur de message va les retirer et les traiter aussi rapidement que possible. Si vous cherchez un moyen d'optimiser le débit dans la file d'attente, vous pouvez envisager de le rendre multithread afin que plusieurs threads retirent les messages de la file d'attente pour appeler le service Web. Vous pouvez facilement le faire en définissant la configuration "concurrConsumers" sur DefaultMessageListenerContainer. Si vous définissez concurrConsumers à 5, 5 threads extraient les messages de la file d'attente à traiter. Cela devient compliqué si vous devez gérer les commandes sur les messages, mais il peut y avoir des solutions à ce problème si c'est le cas.

Answer 2

Je suis d'accord avec la réponse fournie avant moi, mais je peux voir une usecase semblable à ceci très commun dans la pratique. J'ajoute mes deux cents Il peut être valide dans certains cas que vous ne voulez pas faire du travail chronophage dans votre thread onMessage (qui tire le message de Q)

Nous avons quelque chose de similaire dans un flux de travail, où Si l'utilisateur sélectionne une option XYZ sur l'interface graphique, cela signifie que nous devons nous connecter à un autre service web externe pour obtenir ABCD. Dans ce cas, nous n'appelons pas webservice dans onMessage Thread et utilisons ThreadPool pour envoyer et gérer cet appel. En cas de problème lors de l'appel de service Web, nous transmettons cette information à l'interface graphique en tant que message séparé. Il existe un concept d'identificateur de requête qui est conservé dans les messages afin que l'interface graphique puisse relier les messages d'erreur. Vous pouvez utiliser l'implémentation de ExecutorService pour soumettre une tâche.

espérons que ça aide.