Почему DefaultMessageListenerContainer не должен использовать CachingConnectionFactory?
Я читал весеннюю документацию по DefaultMessageListenerContainer
В нем говорится: «Не используйте Spring CachingConnectionFactory Spring в сочетании с динамическим масштабированием. В идеале не используйте его вообще с контейнером прослушивателя сообщений, так как обычно предпочтительно, чтобы сам контейнер-слушатель обрабатывал соответствующее кэширование в течение своего жизненного цикла. Кроме того, остановка и перезапуск контейнера-слушателя будет работать только с независимым локально кэшированным соединением, а не с внешним кэшированием ».
Может ли кто-нибудь объяснить, почему?
- Вам действительно не нужно кэшировать сеансы для контейнеров-слушателей, потому что сеансы долговечны; кеширование очень полезно для частого короткого использования, например, с помощью JmsTemplate.
- Проблема действительно в том, что
cacheConsumers = true(по умолчанию). При использовании динамического масштабирования и остановки слушателя сеанс возвращается в кеш, но брокер не знает, что на этом сеансе никто не будет потреблять, поэтому вы застряли в сообщениях, находящихся в кеше, которые не будут прочитаны до тех пор, пока эта сессия используется повторно при увеличении громкости.
Примечание. Если вы хотите, чтобы JmsTemplate работающий в streamе контейнера, участвовал в транзакции контейнера, вы должны использовать CachingConnectionFactory чтобы производители могли кэшироваться, но вы должны отключить кеширование потребителей на заводе, если у вас есть переменная параллелизм.