Существует ли реализация, похожая на Spring CachingConnectionFactory, которая также закрывает незанятые соединения, пока они не понадобятся снова?

Question

Мы используем Spring CachingConnectionFactory для обработки десятков миллионов сообщений в день в рабочем состоянии с нашим приложением, и это работает хорошо.

Однако мы собираемся сократить количество одновременных подключений к Solace, покаони необходимы, поскольку мы делимся нашей инфраструктурой ESB со многими другими приложениями.Есть ли ленивое продолжение этой весенней фабрики, которая достигает того, что нам нужно?

Answer 1

Я думаю, что здесь необходимо уточнить определение «простоя» - означает ли это, что сообщения не используются и не создаются в течение оставшейся части жизни приложения?Или просто периодическое бездействие, которое может быть или не быть предсказуемым с точки зрения продолжительности бездействия и / или когда это происходит?Более того, как отмечалось в предыдущем ответе, «ленивое управление ресурсами» относится к созданию соединений, а не к их разрушению во время «простоя», что может означать любое количество вещей, как отмечалось ранее.

Как правило, потребители сообщений обычноне сможет предсказать, когда их соединение будет бездействующим, поскольку сообщения могут быть получены в любое время.Для производителей вам может быть лучше знать, когда ваше соединение будет бездействующим, хотя, как правило, не стоит тратить время на повторное создание нового соединения для каждой публикации, как это было бы при использовании JmsTemplate без CCF / SCF.В любом случае следующее может помочь в управлении ресурсами:

1. Если приложение выполняет периодическую работу пакетного типа и не нуждается в создании или потреблении данных между запусками с большими задержками между ними,может иметь смысл сохранять ресурсы либо путем явного управления ресурсами (например, уничтожить / заново создать CCF), либо закрыть и перезапустить, когда это необходимо - Spring Cloud Task может удовлетворить все требования или, возможно, задание cron.

2. Минимизируйте количество обратных вызовов @JmsListener, если это возможно, поскольку каждый из них будет транслироваться в соединение.Очереди Solace поддерживают множественные подписки, а также подстановочные знаки, поэтому может быть возможно объединить подписки в меньшее количество очередей.Если упорядочение не является проблемой, аргумент concurrency может быть передан в @JmsListener, чтобы обеспечить циклическую обработку для нескольких потребителей по одному и тому же соединению.

3. Разгрузка соединений изобщий брокер Solace для выделенного брокера для вашего приложения и настройка VPN-моста или DMR (динамическая маршрутизация сообщений) для общего брокера.

4. Программный брокер PubSub + поддерживает широкий спектруровни масштабирования соединения от 100 до 200 Кб, поэтому вы можете выбрать уровень, обеспечивающий достаточную емкость.Это может быть сделано либо на вашем выделенном брокере, либо на совместно используемом брокере, либо на обоих, в зависимости от ваших требований и ограничений.

Answer 2

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

https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/jms/connection/CachingConnectionFactory.html

Если это для потребителей сообщений, предпочтительно, чтобы сам контейнер слушателя обрабатывал соответствующее кэширование, а не CachingConnectionFactory.DefaultMessageListenerContainer поддерживает динамическое масштабирование.