/ / message-driven-channel-adapter: interrogation de messages faux / fantômes dans la file d'attente - Spring, Spring-Integration, ibm-mq

Message-driven-channel-adapter: Interrogation de messages faux / fantômes à partir d'une file d'attente - Spring, Spring-Integration, ibm-mq

Nous utilisons l’intégration printanière et, quotidiennement, dans nos journaux, nous pouvons voir ci-dessous stacktrace. Les autres adaptateurs JMS fonctionnent bien, mais nous pensons qu’il ne manque que quelque chose:

Configuration d'intégration printanière:

    <jms:message-driven-channel-adapter concurrent-consumers="1" id="jmsInLOAN" destination="queueLOAN" channel="LOANCommonDataChannel" acknowledge="transacted" />

Veuillez trouver ci-dessous les statistiques MQ de Put et Msgsread count, il devrait y avoir un compte exact du message lu par l’adaptateur. Je suis inquiet à propos de Spring Integration ", un adaptateur de canal piloté par message, permettant de lire des messages supplémentaires dans la file d'attente. Toute aide serait la bienvenue.

entrer la description de l'image ici

WARN  07/Jan/2016 09:04:15,438 [org.springframework.jms.listener.DefaultMessageListenerContainer#23-1] springframework.jms.listener.DefaultMessageListenerContainer - [SYSTEM_ID=HBUSLOANIQ] [MESSAGE_ID=null] Execution of JMS message listener failed, and no ErrorHandler has been set.
org.springframework.integration.MessagingException: unsupported payload type [com.ibm.jms.JMSMessage]
at org.springframework.integration.xml.DefaultXmlPayloadConverter.convertToDocument(DefaultXmlPayloadConverter.java:76)
at org.springframework.integration.xml.DefaultXmlPayloadConverter.convertToNode(DefaultXmlPayloadConverter.java:88)
at org.springframework.integration.xml.router.XPathRouter.getChannelIdentifiers(XPathRouter.java:119)
at org.springframework.integration.router.AbstractMessageRouter.determineTargetChannels(AbstractMessageRouter.java:247)
at org.springframework.integration.router.AbstractMessageRouter.handleMessageInternal(AbstractMessageRouter.java:211)

Réponses:

0 pour la réponse № 1

Il semble que vous transmettiez le message JMS non converti (com.ibm.jms.JMSMessage) au convertisseur de charge utile XML ...

org.springframework.integration.MessagingException: unsupported payload type [com.ibm.jms.JMSMessage]
at org.springframework.integration.xml.DefaultXmlPayloadConverter.convertToDocument(DefaultXmlPayloadConverter.java:76)

Vous avez peut-être mis extract-payload à false ?

Bien que ce ne soit pas dans la configuration que vous montrez.

L'activation de la journalisation DEBUG indique le type de charge utile des messages transitant par le système.


0 pour la réponse № 2

La question était en raison de la validité etpoisonous (qui a un type de charge utile [com.ibm.jms.JMSMessage]) que nous étions en train de mettre dans la file d'attente. Les messages valides ont bien été traités, mais les messages toxiques ne peuvent pas être digérés par application et envoyés à BackoutQueue.

Dans notre cas, le seuil de BOQ est égal à 3, ce qui signifie 3fois mon application essaiera de consommer un message spécifique et si le message est retourné 3 fois, il sera déplacé vers la file d'attente BOQ et (msgs read - msgs put) / 3 sur LOAIQ == les messages envoyés à la file d'attente BOQ à cet intervalle d'échantillonnage . À partir des messages placés dans la file d'attente BOQ, nous pouvons voir le nombre de messages en attente de la file d'attente LOAIQ. C’est pourquoi le nombre de lectures de messages est supérieur à celui des messages reçus. entrer la description de l'image ici