Spring DefaultMessageListenerContainer - слушатель не читает сообщения в Websphere MQ - PullRequest
Новая
       37

Spring DefaultMessageListenerContainer - слушатель не читает сообщения в Websphere MQ

4 голосов
/ 14 ноября 2011

Я использую Spring 3.0 - DefaultMessageListenerContainer для подключения к Websphere 6 MQ.На MQ уже есть сообщения.Когда я запускаю свой тест, запускается слушатель, реализующий SessionAwareMessageListener.Но onMessage () не вызывается.Таким образом, проблема в том, что сообщения, уже находящиеся в очереди, не читаются.

Согласно документам, autoStartup имеет значение true по умолчанию (и я не изменял это).Согласно моему пониманию, при запуске слушатель должен прочитать Очередь для любых существующих сообщений, и должен быть вызван onMessage ().Пожалуйста, дайте мне знать, если это понимание неверно.

Вот фрагмент из файла конфигурации: 

    <bean id="jmsContainer"
        class="org.springframework.jms.listener.DefaultMessageListenerContainer">
        <property name="connectionFactory" ref="jmsQueueConnectionFactory" />
        <property name="destinationName">
            <value>${queue}</value>
        </property>
        <property name="messageListener" ref="exampleMessageListener" />
        <property name="concurrentConsumers" value="1" />
        <property name="maxConcurrentConsumers" value="1" />
        <property name="idleTaskExecutionLimit" value="4" />
        <property name="maxMessagesPerTask" value="4" />
        <property name="receiveTimeout" value="5000" />
        <property name="recoveryInterval" value="5000" />
        <property name="sessionTransacted" value="true" />
        <property name="transactionManager" ref="jmsTransActionManager" />
    </bean>

Примечание: ошибки / исключения нет, тестовое приложение запускается нормально.

Любые указатели для решения этой проблемы будут очень полезны.

Спасибо,
RJ

Ответы [ 2 ]

1 голос
/ 15 ноября 2011

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

Позже, когда я включил Менеджер транзакций, слушатель помещал сообщение обратно в очередь (показывая предупреждение как Отклонениеполученное сообщение из-за того, что контейнер получателя был остановлен за это время ).Поскольку это было предупреждение, и мой регистратор находился на уровне отладки, я пропустил это раньше.

Помещение thread.sleep в тестовый класс обеспечило, чтобы он работал дольше, и слушатель мог прочитать всесообщения в очереди в порядке приоритета:)

ура,
RJ

0 голосов
/ 17 января 2014

Это, на самом деле, не ответ, но я не хочу создавать новый вопрос для той же проблемы.

Я инициализировал контекст Spring 

ctx = new ClassPathXmlApplicationContext("classpath:" + args[0]);

, прочитал конфигурацию изатем вызвал (из-за предупреждения, что ресурс не был закрыт): 

ctx.stop();

, и я не понял, что это остановит мои компоненты, после одного дня отладки я нашел это сообщение в журнале 

DEBUG o.s.c.s.DefaultLifecycleProcessor - Asking bean 'messageListenerContainer' of type [class org.springframework.jms.listener.DefaultMessageListenerContainer] to stop
...