0
votes

Given that I have application running in IBM WebSphere AS 8.5.5.9, connected to IBM WebSphere MQ 7.0 via JMS (resolved via JNDI), using spring-integraion-jms(4.2.5) inbound-gateway configured as follows:

    <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 message got processed and status reply message arrives on channel channel.response.message. When inbound message have incorrect jms_replyTo header (i.e. non-existent queue) following exception raises, ignoring error-channel setting (any other exceptions during integration flow handled correctly):

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

Then message got rolled back, and redelivered, thus making infinite loop. Is there any workarounds or best practices for this issue apart from Handling poison messages in WebSphere MQ classes for JMS?

1

1 Answers

0
votes

The error channel is intended to catch exceptions in the downstream flow from the gateway, the sending of the reply is not currently in the scope of the error channel handling.

Last year we extended the scope to include message conversion before the message is sent to the downstream flow, but the reply processing is still outside that scope.

We could consider adding it but right now, the only work-around would be to use the poison message stuff. Alternatively, if you know which replyTo queues are valid in your application, you can check the jms_replyTo header and throw an exception from your flow.