Unendliche JMS-Nachricht Redelivery-Schleife, wenn replyTo auf nicht vorhandene Warteschlange festgelegt

Question

Vorausgesetzt, ich habe Anwendung in IBM WebSphere AS 8.5.5.9, über JMS (aufgelöst über JNDI) mit IBM WebSphere MQ 7.0 ausgeführt, mit Spring-Integraion-Jms (4.2 .5) Inbound-Gateway wie folgt konfiguriert:

<int-jms:inbound-gateway id="requestGateway" 
         connection-factory="jndiConnectionFactory" 

         request-destination="jndiQueueInput" 
         request-channel="channel.request.message" 

         reply-channel="channel.response.message" 
         default-reply-destination="jndiQueueOutput" 

         error-channel="errorChannel"/> 

Inbound Nachricht erhalten verarbeitet und Statusantwortnachricht auf Kanal ankommt channel.response.message. Wenn eingehende Nachricht haben falsche jms_replyTo Header (dh inexistent queue) folgende Ausnahme auslöst, fehlerKanalEinstellung ignoriert (alle anderen Ausnahmen während des Fließens Integration gehandhabt korrekt):

WARN o.s.j.l.DefaultMessageListenerContainer - Execution of JMS message listener failed, and no ErrorHandler has been set. 
com.ibm.msg.client.jms.DetailedInvalidDestinationException: JMSWMQ2008: Failed to open MQ queue 'BLABLABLA'. 
    at com.ibm.msg.client.wmq.common.internal.Reason.reasonToException(Reason.java:498) 
    at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:216) 
    at com.ibm.msg.client.wmq.internal.WMQMessageProducer.checkJmqiCallSuccess(WMQMessageProducer.java:1086) 
    at com.ibm.msg.client.wmq.internal.WMQMessageProducer.checkJmqiCallSuccess(WMQMessageProducer.java:1044) 
    at com.ibm.msg.client.wmq.internal.WMQMessageProducer.access$800(WMQMessageProducer.java:71) 
    at com.ibm.msg.client.wmq.internal.WMQMessageProducer$SpiIdentifiedProducerShadow.initialise(WMQMessageProducer.java:790) 
    at com.ibm.msg.client.wmq.internal.WMQMessageProducer.<init>(WMQMessageProducer.java:1020) 
    at com.ibm.msg.client.wmq.internal.WMQSession.createProducer(WMQSession.java:926) 
    at com.ibm.msg.client.jms.internal.JmsSessionImpl.createProducer(JmsSessionImpl.java:1323) 
    at com.ibm.mq.jms.MQSession.createProducer(MQSession.java:682) 
    at com.ibm.ejs.jms.JMSMessageProducerHandle.<init>(JMSMessageProducerHandle.java:134) 
    at com.ibm.ejs.jms.JMSSessionHandle.createProducer(JMSSessionHandle.java:1869) 
    at org.springframework.integration.jms.ChannelPublishingJmsMessageListener.sendReply(ChannelPublishingJmsMessageListener.java:464) 
    at org.springframework.integration.jms.ChannelPublishingJmsMessageListener.onMessage(ChannelPublishingJmsMessageListener.java:358) 
    at org.springframework.jms.listener.AbstractMessageListenerContainer.doInvokeListener(AbstractMessageListenerContainer.java:721) 
    at org.springframework.jms.listener.AbstractMessageListenerContainer.invokeListener(AbstractMessageListenerContainer.java:681) 
    at org.springframework.jms.listener.AbstractMessageListenerContainer.doExecuteListener(AbstractMessageListenerContainer.java:651) 
    at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.doReceiveAndExecute(AbstractPollingMessageListenerContainer.java:315) 
    at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.receiveAndExecute(AbstractPollingMessageListenerContainer.java:253) 
    at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.invokeListener(DefaultMessageListenerContainer.java:1158) 
    at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.executeOngoingLoop(DefaultMessageListenerContainer.java:1150) 
    at org.springframework.jms.listener.DefaultMessageListenerContainer$AsyncMessageListenerInvoker.run(DefaultMessageListenerContainer.java:1047) 
    at java.lang.Thread.run(Thread.java:785) 
Caused by: com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2085' ('MQRC_UNKNOWN_OBJECT_NAME'). 
    at com.ibm.msg.client.wmq.common.internal.Reason.createException(Reason.java:204) 
    ... 21 common frames omitted 

Dann wurde Nachricht zurückgerollt, und redelivered und somit Endlosschleife machen. Gibt es abgesehen von Handling poison messages in WebSphere MQ classes for JMS Workarounds oder Best Practices für dieses Problem?

Answer 1

Der Fehlerkanal soll Ausnahmen im Downstream-Fluss vom Gateway abfangen, das Senden der Antwort liegt derzeit nicht im Bereich der Fehlerkanalbehandlung.

Im letzten Jahr haben wir den Bereich um die Nachrichtenkonvertierung erweitert, bevor die Nachricht an den Downstream-Fluss gesendet wird, aber die Antwortverarbeitung liegt immer noch außerhalb dieses Bereichs.

Wir könnten darüber nachdenken, es hinzuzufügen, aber im Moment wäre die einzige Möglichkeit, die Giftnachricht zu verwenden. Wenn Sie wissen, welche Antwort für Warteschlangen in Ihrer Anwendung gültig ist, können Sie alternativ den Header jms_replyTo überprüfen und eine Ausnahme von Ihrem Nachrichtenfluss auslösen.