WebSphere MQ wmq.jmsra looping after exception in MDB

Question

I'm faceing a problem with JBoss EAP 6 and WebSphere MQ. I've developed a message driven bean:

@MessageDriven(activationConfig = {
    @ActivationConfigProperty(propertyName = "useJNDI", propertyValue = "true"),
    @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
    @ActivationConfigProperty(propertyName = "destination", propertyValue = "java:/jms/VGT.EXTERN.IN"),
    @ActivationConfigProperty(propertyName = "clientID", propertyValue = "VGT_BYSENDINGSYSTEMDISPATCHERMDB") })
@Pool(value = "BySendingSystemDispatcherMDB-pool")
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class BySendingSystemDispatcherMDB implements javax.jms.MessageListener {

private Logger logger = Logger.getLogger(getClass());

@Inject
@Named
BySendingSystemDispatcher bySendingSystemDispatcher;

@Resource
MessageDrivenContext mdc;

@Inject
@Named
Listener listener;

@Override
public void onMessage(Message message) {
    try {
        // Weiterbearbeitung deligieren
        bySendingSystemDispatcher.onMessage(message);
    } catch (JMSException e) {
        listener.handleExceptionWhenMessageIsPoisend(e);
        logger.error(e.getLinkedException(), e);
        mdc.setRollbackOnly();
    } catch (JAXBException e) {
        mdc.setRollbackOnly();
        listener.handleExceptionWhileProcessingMessage(message, e);
        logger.error(e.getMessage(), e);
    } catch (ClassCastException e) {
        logger.error(e.getMessage(), e);
        mdc.setRollbackOnly();
    } catch (Exception e) {
        logger.error(e.getMessage(), e);
        mdc.setRollbackOnly();
    } finally {
        // logging
        if (logger.isDebugEnabled()) {
            String id = null;
            try {
                id = message.getJMSMessageID();
                logger.debug(((TextMessage) message).getText());
            } catch (Exception e) {
                logger.debug("logging of message - " + id + " failed");
            }
        }

    }

}

The method bySendingSystemDispatcher.onMessage(message) is throwing an exception derived from java.lang.Exception, annotated with @ApplicationException(rollback=true). If this happens, the message will be redeliver 5 times, as configured and after that it loops within the ressource adapter and will not be delivered anymore. I've checked the same scenario with HornetQ and it works as expected.

The following exception will be thrown by MQ

Class : class javax.jms.JMSException
Stack : com.ibm.msg.client.commonservices.trace.Trace.ffst(Trace.java:1611)
      : com.ibm.msg.client.wmq.common.internal.messages.WMQSendMarshal.constructMQMD(WMQSendMarshal.java:287)
      : com.ibm.msg.client.wmq.common.internal.messages.WMQSendMarshal.exportMQMDAndMessageBuffers(WMQSendMarshal.java:503)
      : com.ibm.msg.client.wmq.common.internal.messages.WMQSendMarshal.exportMQMD(WMQSendMarshal.java:567)
      : com.ibm.msg.client.wmq.internal.WMQPoison$PoisonMessage.calculateMqmdAndBuffers(WMQPoison.java:1816)
      : com.ibm.msg.client.wmq.

One interesting point is, that you can find a backout count in the MQMD-header which exceeds the backout threshold.

Any idea what happens and how to be solved?

Jörg

Answer 1

We've found the reason why the ressource-adapter has been forced to loop. Due to a mistyping we had a wrong configuration of the boq, the max-msg-len attribute was 8 times smaller than the referencing queue. If there was a message which was larger then the max-msg-len of the boq and an exception forced it to move to the boq, the ressource-adapter tried to put it to the boq and failed. Normally the ressouce-adapter then should move it to the dlq, but this failed also, because of the loss of the transaction. After the failure to move to the dlq the ressource-adapter did not discard the message but it tried again to move it to the boq, which failed again and the loop was started.

In my opinion the behaviour of the ressource-adapter is not really correct, but if one synchronizes the max-msg-len attributes the problem should not occur.

Thanks to Umapathy for his support.

Jörg