OSB 11.1.1.4 MQ JMS Proxy - Endless Redelivery of Messages (Doc ID 1401497.1)

Last updated on JUNE 19, 2016

Applies to:

Oracle Service Bus - Version 11.1.1.3.0 to 11.1.1.6.0 [Release 11g]
Information in this document applies to any platform.

Symptoms


You use an Oracle Service Bus (OSB) JMS Proxy against IBM MQ.
If there arrives a poison / empty message we throw below exception:


 <Error> <WliSbTransports> <DispatchThread: 1> <> <>
<6a76f477b57fb9e4:-3c0fbc6f:131845c4538:-8000-00000000000000b6>
<1312188017791> <BEA-381502> <Exception in JmsInboundMDB.onMessage:
com.bea.wli.sb.transports.TransportException: Unexpected type of message received: com.ibm.jms.JMSMessage
com.bea.wli.sb.transports.TransportException: Unexpected type of message received: com.ibm.jms.JMSMessage
at com.bea.wli.sb.transports.jms.JmsInboundMessageContext.<init>(JmsInboundMessageContext.java:105)
at com.bea.wli.sb.transports.jms.JmsInboundMDB.onMessage(JmsInboundMDB.java:122)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:600)
at com.bea.core.repackaged.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:310)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
at com.bea.core.repackaged.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:89)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:131)
at  com.bea.core.repackaged.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:119)
at com.bea.core.repackaged.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at  com.bea.core.repackaged.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy149.onMessage(Unknown Source)
at weblogic.ejb.container.internal.MDListener.execute(MDListener.java:519)
at weblogic.ejb.container.internal.MDListener.transactionalOnMessage(MDListener.java:424)
at weblogic.ejb.container.internal.MDListener.onMessage(MDListener.java:326)
at com.ibm.mq.jms.MQMessageConsumer$FacadeMessageListener.onMessage(MQMessageConsumer.java:399)
at com.ibm.msg.client.jms.internal.JmsMessageConsumerImpl$JmsProviderMessageListener.onMessage(JmsMessageConsumerImpl.java:904)
at com.ibm.msg.client.wmq.internal.WMQAsyncConsumerShadow.honourNoLocal(WMQAsyncConsumerShadow.java:551)
at com.ibm.msg.client.wmq.internal.WMQAsyncConsumerShadow.consumer(WMQAsyncConsumerShadow.java:385)
at com.ibm.mq.jmqi.remote.internal.RemoteAsyncConsume.driveConsumer(RemoteAsyncConsume.java:1523)
at com.ibm.mq.jmqi.remote.internal.RemoteDispatchThread.run(RemoteDispatchThread.java:394)
at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueueItem.java:209)
at com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(SimpleWorkQueueItem.java:100)
at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueItem.java:224)
at com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueItem(WorkQueueManager.java:298)
at com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1220)
>


Now you observe two different results:

1.) The Queue is configured as " Persistent"
Under Storage-Section of the MQ queue a Backout Requeue Queue is defined
Backout Threshold is set to "3".
Rollback is is handled correctly and after the configured number of retries the message will be moved to the Backout Requeue Queue.

This is how you expect it to work.


2.) The Queue is configured as " Non-Persistent"
Under Storage-Section of the MQ queue a Backout Requeue Queue is defined
Backout Threshold is set to "3".

Backout Threshold is not taken into account - and the message will be redelivered forever.

There is a difference in persistent to non-persistent MQ implementation:

Non-Persistent MQ messages in a non-transacted session should be redelivered to the onMessage() method.
While the messages are delivered to the onMessage() method, there is no count or limit to redeliver it. WMQ classes for JMS reliver the message from its own buffer(JVM cache) while it doesn'™t increment backoutCount and there will be no requeue operation on WMQ because the message flows in a loop between WMQ classes for JMS and JMS Client application.

Cause

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms