Я использую 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 работали нормально. Тем не менее, вы ищете ответ, действительно ли это действительный подход.
Это должно просто произойти в результате очереди определяется с очередью отката и сосчитать. Можете ли вы добавить свое определение очереди в информацию в своем вопросе, пожалуйста? –
Был бы очень заинтересован в указателях конфигурации Spring JMS, которые вы видели в работе MQ. Если вы можете опубликовать это, то ответ будет самым ценным. Огромное спасибо! –
Пожалуйста, добавьте вывод сообщений об ошибках в диспетчер очереди AMQERR01.LOG, который покажет, в чем причина ошибки 2035 MQRC_NOT_AUTHORIZED. –