При использовании следующей заводской настройки на @JmsListener (с параллелизмом 5):
DefaultJmsListenerContainerFactory factory = new DefaultJmsListenerContainerFactory();
CachingConnectionFactory cachingConnectionFactory = new CachingConnectionFactory(connectionFactory);
cachingConnectionFactory.setSessionCacheSize(10);
factory.setConnectionFactory(cachingConnectionFactory);
factory.setConnectionFactory(connectionFactory);
factory.setSessionTransacted(true);
factory.setErrorHandler(errorHandler());
factory.setCacheLevel(DefaultMessageListenerContainer.CACHE_CONNECTION);
Я сталкиваюсь с проблемами, когда, если сообщений теперь мало, они как бы помещаются в очередь и не будут подняты, пока объемы не станут огромными, а затем они будут обработаны. Итак, я сталкиваюсь с этим: Почему DefaultMessageListenerContainer не должен использовать CachingConnectionFactory? и теперь удалил CachingConnectionFactory, и все кажется хорошо.
Недавно я обратился к отладке для ведения журнала и увидел этот сеанс продолжает открываться и закрываться для каждого
запросов и переполняет журналы отладки. Я подумал, что может быть лучше, поэтому я поигрался с cacheLevel, установив его на:
factory.setCacheLevel(DefaultMessageListenerContainer.CACHE_CONSUMER);
Выдержка из javado c:
* Constant that indicates to cache a shared JMS {@code Connection}, a JMS
* {@code Session}, and a JMS MessageConsumer for each listener thread.
* @see #setCacheLevel
И это на самом деле улучшает производительность и выглядит хорошо, и без проблемы, с которой я столкнулся с CachingConnectionFactory. Если я правильно понял, CachingConnectionFactory кэширует сеанс ... и setCacheLevel (DefaultMessageListenerContainer.CACHE_CONSUMER) тоже ... Или они совершенно разные в терминах кеширования сеанса? Интересно, почему я не сталкиваюсь с той же проблемой с cachingConnectionFactory, когда я включил cacheLevel для кеширования сеанса и потребителя.
Кто-нибудь может пролить свет?