Запретить использование CachingConnectionFactory с DefaultJmsListenerContainerFactory

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

Начиная с нуля, я использую последнюю версию Spring JMS (4.1.2).

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

<bean id="cachedConnectionFactory" 
          class="org.springframework.jms.connection.CachingConnectionFactory"
        p:targetConnectionFactory-ref="jmsConnectionFactory"
        p:sessionCacheSize="3" />

<bean id="jmsListenerContainerFactory"
          class="org.springframework.jms.config.DefaultJmsListenerContainerFactory"
          p:connectionFactory-ref="cachedConnectionFactory"
          p:destinationResolver-ref="jndiDestinationResolver"
          p:concurrency="3-5"
          p:receiveTimeout="5000" />

Но я думаю, что могу ошибаться, поскольку DefaultJmsListenerContainerFactory будет создавать обычные DefaultMessageListenerContainerS. И, как указано в doc, CachingConnectionFactory не следует использовать с контейнером прослушивателя сообщений...

  • Даже если я использую новый класс Spring 4.1 DefaultJmsListenerContainerFactory, ответ из post все еще действует (cacheConsumers = true может быть проблемой + не нужно кэшировать сеансы для контейнеров прослушивателя, потому что сеансы долгоживущие), верно?
  • Вместо использования CachingConnectionFactory я должен использовать SingleConnectionFactory (а не непосредственно реализацию брокера)?
  • Если класс SingleConnectionFactory действительно следует использовать, следует ли для свойства «reconnectOnException» установить значение true (как это делается в CachingConnectionFactory) или новый метод «setBackOff» (из DefaultJmsListenerContainerFactory) имеет дело с теми же проблемами?

Спасибо за любые советы


spring spring-jms
person Benjamin C    schedule 19.11.2014    source источник

Ответы (1)


arrow_upward
0
arrow_downward

  • Верный.
  • В использовании SingleConnectionFactory нет особой пользы, если только вы не хотите использовать одно соединение для нескольких контейнеров; DMLC будет использовать одно соединение с фабрикой поставщика по умолчанию для всех потоков-потребителей (cacheLevel >= CACHE_CONNECTION), если не настроено TransactionManager.
  • Контейнеры будут обрабатывать переподключение — даже до «нового» свойства backOff — backOff просто добавляет больше сложности в алгоритм переподключения — раньше он просто повторял попытку каждые n секунд (по умолчанию 5).

Как указано в процитированном вами ответе, можно использовать CCF, если вы отключите кэширование потребителей.

Исправление: Да, при использовании SingleConnectionFactory вам необходимо установить для reconnectOnException значение true, чтобы контейнер правильно восстановил соединение. В противном случае он просто раздает устаревшее соединение.

person Gary Russell    schedule 19.11.2014