2015-05-22 14 views
1

Я столкнулся с проблемой с JBoss EAP 6 и WebSphere MQ. Я разработал управляемые сообщения компонента:WebSphere MQ wmq.jmsra цикл после исключения в MDB

@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"); 
      } 
     } 

    } 

} 

Метода bySendingSystemDispatcher.onMessage (сообщение) бросает исключение, полученное из java.lang.Exception, аннотированное с @ApplicationException (откат = истина). Если это произойдет, сообщение будет обновляться 5 раз, как и было настроено, и после этого оно будет проходить через адаптер ressource и больше не будет доставлено. Я проверил тот же сценарий с HornetQ, и он работает так, как ожидалось.

следующее исключение будет брошена 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. 

Один интересный момент в том, что вы можете найти количество отката в MQMD-заголовок, который превышает порог отката.

Любая идея, что происходит и как ее решить?

Йорг

+0

Есть ли какие-либо другие ошибки, возникшие в/var/mqm/errors? Есть ли какие-либо файлы fdc? – Umapathy

+0

FDC написан, но в этом отчете нет ничего очевидного. По крайней мере, исключение, которое я указал в моей публикации, находится в FDC. Вы ищете что-то особенное? –

+0

Исключение возникает во время генерации файла FDC, поэтому задается вопросом, что его сообщение ничего. Определите «работу как ожидалось». Отбрасывается ли сообщение HornetQ? Также вы определили порог очереди резервного копирования и резервного копирования в очереди VGT.EXTERN.IN? – Umapathy

ответ

0

Мы нашли причину, почему Ressource-адаптер был вынужден петли. Из-за туманности у нас была неправильная конфигурация boq, атрибут max-msg-len был в 8 раз меньше, чем ссылочная очередь. Если было сообщение, которое было больше, чем max-msg-len из boq и исключение заставили его перейти на boq, адаптер ressource попытался перевести его в boq и не смог. Обычно адаптер ressouce затем должен переместить его в dlq, но это также не удалось из-за потери транзакции. После отказа от перехода на dlq адаптер ressource не отбросил сообщение, но он снова попытался переместить его в boq, который снова не удался, и цикл был запущен.

По-моему, поведение адаптера ressource не совсем корректно, но если синхронизировать атрибуты max-msg-len, проблема не должна возникать.

Благодаря Umapathy за поддержку.

Jörg