Блог

Главная - Вопросы по программированию - Проблема с производительностью при использовании DefaultMessageListenerContainer с CachingConnectionFactory

Проблема с производительностью при использовании DefaultMessageListenerContainer с CachingConnectionFactory

#spring-integration #spring-jms

#spring-интеграция #spring-jms

Вопрос:

В нашем приложении мы используем SingleConnectionFactory с DefaultMessageListenerContainer, использующим сервер IBM MQ DefaultMessageListenerContainer, с точки зрения производительности приложение работает довольно хорошо, однако в конце MQ наше приложение открывает слишком много новых подключений случайным образом. Вот текущая конфигурация, которую мы имеем.

Ответ №1:

Попробуйте использовать это вместо кэширования или single:

 <bean id="connectionFactory" class="org.springframework.jms.connection.DelegatingConnectionFactory">
    <property name="targetConnectionFactory" ref="primaryRawInputConnectionFactory" />
    <property name="shouldStopConnections" value="true"/>
</bean>

Комментарии:

1. Спасибо, Артем. Каковы преимущества использования этого делегирующего ConnectionFactory и как насчет настроек DefaultMessageListenerContainer по умолчанию?

2. Прочтите его JavaDocs, пожалуйста. Я не вижу никаких проблем с вашей DefaultMessageListenerContainer конфигурацией.

3. Я все еще могу использовать <имя свойства =»cacheLevelName» значение =»CACHE_CONSUMER» /> в контейнере?

4. Что ж, это действительно лучше для кэширования потребителя для постоянно прослушивающего контейнера.

5. Потрясающее спасибо… Интересно, что произойдет, если диспетчер очередей не работает, попытается ли мое приложение повторно подключиться к серверу?… Я знаю, что, по крайней мере, у меня есть такая опция для заводских настроек одиночного или кэширующего соединения