2014-10-03 2 views
1

Я использую JMS Spring (версия 3.1.2) listener-container с JMS connectionFactory, исходя из настроек JNDI от WebSphere 7. Приложение обрабатывает сообщения (put/get) правильно, но настройки , установленные в диспетчере очереди MQ, похоже, не работают.Spring `jms: listener-container` и очереди резервного копирования IBM MQ

Чтобы не использовать потребление сообщений, я использую весенние транзакции с setRollbackOnly(), и это увеличивает свойство «Количество отводов», поскольку я вижу, что число, увеличивающееся с помощью «WebSphere MQ Explorer», указывает на удаленную очередь.

Чтение через несколько документов IBM описывает, что клиент IBM MQ JMS должен переместить плохое сообщение в очередь резервного копирования. Spring listener-container, похоже, не использует MQ-клиент таким образом, который позволяет это поведение. Счет backout просто продолжает увеличиваться, как будто команда Requeue не работает.

Является ли Spring JMS способной использовать эту функциональность? Есть ли что-то, что необходимо установить в listener-container, чтобы он мог обрабатывать переход в очереди резервного копирования IBM MQ?

Моя конфигурация выглядит следующим образом:

<tx:jta-transaction-manager/> 
<jee:jndi-lookup id="connectionFactory" 
     jndi-name="java:comp/env/jms/myapp_queuefactory"/> 
<jms:listener-container 
     connection-factory="connectionFactory" 
     transaction-manager="transactionManager"> 
    <jms:listener destination="ONEQUEUE" ref="oneQueueListener" /> 
    <jms:listener destination="ANOTHERQUEUE" ref="anotherQueueListener" /> 
    <!-- many more --> 
<jms:listener-container/> 

Очередь IBM MQ устанавливается с «отката снова поставить в очередь» установлен ONEQUEUE.BOQ и «Порог» отката к 5.

Мой весенний сообщение код приводится POJO Java выглядит следующим образом:

@Transactional 
public class MyQueueMDBean implements javax.jms.MessageListener { 
    public void onMessage(javax.jms.Message msg) { 
     try { 
      // some code that throws some exception ... 
     } catch (Exception e) { 
      TransactionInterceptor.currentTransactionStatus().setRollbackOnly();  
     } 
    } 
} 

StackTrace ОШИБКА

После того, как сообщение было откат 5 раз, слушатель начинает не суметь соединить, в качестве вывода к журналам:

[org.springframework.jms.listener.DefaultMessageListenerContainer # 3-14870] WARN org.springframework.jms.listener.DefaultMessageListenerContainer - настройка списка сообщений JMS ener invoker завершился неудачно для пункта назначения «ONEQUEUE» - попытка восстановления. Причина: MQJMS1079: невозможно записать сообщение в очередь мертвой буквы; inested exception is com.ibm.mq.MQException: MQJE001: Код завершения '2', причина '2035'.

Похоже, что что-то происходит с разрешением на откат сообщения, или фактическая резервная очередь не возвращается правильно, что было неожиданным, так как get/puts работали нормально. Тем не менее, вы ищете ответ, действительно ли это действительный подход.

+2

Это должно просто произойти в результате очереди определяется с очередью отката и сосчитать. Можете ли вы добавить свое определение очереди в информацию в своем вопросе, пожалуйста? –

+0

Был бы очень заинтересован в указателях конфигурации Spring JMS, которые вы видели в работе MQ. Если вы можете опубликовать это, то ответ будет самым ценным. Огромное спасибо! –

+0

Пожалуйста, добавьте вывод сообщений об ошибках в диспетчер очереди AMQERR01.LOG, который покажет, в чем причина ошибки 2035 MQRC_NOT_AUTHORIZED. –

ответ

1

JMS Client будет помещать ядовитые сообщения в очередь резервного копирования, определенную в BackoutRequeueQueue очереди (BOQNAME) после того, как количество обратных запросов превышает количество, указанное в BackoutThreshold (BOTHRESH). Это означает, что пользователю, работающему с JMS-приложением, нужен не только доступ к очереди приложений, но и доступ к очереди очереди именованных резервных копий.

Если очередь резервного копирования недоступна или не определена, будет использоваться очередь мертвых букв менеджера очереди (атрибут DEADQ).

Невозможность предоставить идентификатор пользователя +put доступ к очереди резервного копирования и/или DLQ приведет к коду причины MQRC_NOT_AUTHORIZED (2035), когда ядовитое сообщение соответствует критериям, которые должны быть отправлены в очередь резервного копирования.

2035 будет сообщено исключениями JMS, а точные отсутствующие полномочия в точном имени очереди для точного идентификатора пользователя будут сообщены в журнале ошибок диспетчера очереди.

Связанное Чтение

  1. Handling poison messages in WebSphere MQ classes for JMS
Смежные вопросы