Истечение времени ожидания Spring JMS при использовании из очереди WebSphere MQ

У меня есть клиент на основе Spring JMS, который асинхронно прослушивает «триггеры» на QUEUE1, они указывают, что есть сообщение, готовое для использования в другой очереди, QUEUE2.

Потребление в QUEUE2 осуществляется с помощью класса JmsTemplate, настроенного следующим образом:

<bean id="jmsTemplate" class="org.springframework.jms.core.JmsTemplate">
        <constructor-arg ref="gpyConnectionFactory" />
        <property name="destinationResolver" ref="jndiDestinationResolver" />
        <property name="receiveTimeout" value="100" />
    </bean>

Обратите внимание на небольшой параметр receiveTimeout. Это значение уже было таким, прежде чем взять на себя ответственность за это приложение.
СЕЙЧАС я заметил, что иногда, особенно когда QUEUE2 содержит относительно большое сообщение, вызов

jmsTemplate.receiveSelectedAndConvert(destinationName, mqSelector);

извлекает объект NULL, поэтому вполне вероятно, что время ожидания истекло!

Насколько мне известно, согласно спецификации JMS (поправьте меня, если я ошибаюсь) тайм-аут истечет, только если в очереди нет доступных сообщений. Текущий сценарий заставляет меня поверить, что из-за размера сообщения и из-за того, что наверняка есть сообщение в этой очереди, тайм-аут истекает, потому что у потребителя нет достаточно времени, чтобы прочитать все большое сообщение. Возможно ли все это?

Поставщик - WebSphere MQ.

Обязательно установлю большее значение тайм-аута.


timeout ibm-mq spring-jms
person vortex.alex    schedule 10.12.2013    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Тайм-аут не обрабатывается Spring, он обрабатывается в библиотеке JMS поставщика ..._ 1_.

Брокер «подталкивает» сообщение к потребителю, когда оно поступает в очередь, но, да, для передачи большого сообщения потребуется определенное время, и, безусловно, возможен тайм-аут операции consumer.receive() (возможно, многократно) до тех пор, пока сообщение не будет отправлено. полностью перенесен.

На самом деле обработка выполняется кодом поставщика, но я сомневаюсь, что кто-то заблокирует получение, потому что сообщение находится в процессе передачи.

Таким образом, помещение сообщения в одну очередь не является надежным способом уведомления о том, что сообщение доступно в другой очереди.

Рассмотрите возможность получения только из реальной очереди (или используйте подход на основе сообщений вместо JmsTemplate).

person Gary Russell    schedule 10.12.2013