1

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

Jörg
  • 13
  • 3
  • Is there any other errors thrown in /var/mqm/errors? Is there any fdc files generated? – Umapathy May 22 '15 at 13:25
  • An FDC is written but nothing really obvious statements are in this report. At least the exception, which I pointed out in my posting, is in the FDC. Are you looking for something special? – Jörg May 26 '15 at 06:36
  • The exception is thrown during FDC file generation so wondered if its reporting anything. Define "working as expected". Is the message discarded by HornetQ? Also did you define the backout queue and backout threshold on VGT.EXTERN.IN queue? – Umapathy May 26 '15 at 08:56
  • Thanks for your response, "works as expected" means, that there where 5 retries and afterwards pushed to the deadletter-queue. In the MQ-environment backout threshold (5) as well as backout queue is defined. – Jörg May 26 '15 at 12:34

1 Answers1

0

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

Jörg
  • 13
  • 3