From 13e7cf398764f212e117d05464c8b3a1dba715ca Mon Sep 17 00:00:00 2001 From: Michal Domagala Date: Sat, 1 Aug 2020 03:18:40 +0200 Subject: [PATCH] Modify DefaultMessageListenerContainer javadoc Issue https://github.com/spring-projects/spring-framework/issues/15210 reports problem with maxMessagePerTask and CachingConnectionFactory. Result of the issue is javadoc section which discourages from CachingConnectionFactory with dynamic scalling. But dynamic scaling described in the javadoc is achieved by method setMaxConcurrentConsumers, not setMaxMessagePerTask. I can't find issue 15210 details, but CachingConnectionFactory is typical setup in Spring world. For example, guide https://github.com/spring-guides/gs-messaging-jms creates context with DefaultMessageListenerContainer + CachingConnectionFactory. For that reason I assume that DefaultMessageListenerContainer + CachingConnectionFactory + dynamic scaling with setMaxConcurrentConsumers is correct. I deleted misleading Javadoc section and added relevant discouraging section to Javadoc of method setMaxMessagePerTask If I am wrong please reject my PR --- .../jms/listener/DefaultMessageListenerContainer.java | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/spring-jms/src/main/java/org/springframework/jms/listener/DefaultMessageListenerContainer.java b/spring-jms/src/main/java/org/springframework/jms/listener/DefaultMessageListenerContainer.java index eb6c46aa8d62..9fa1661e00a3 100644 --- a/spring-jms/src/main/java/org/springframework/jms/listener/DefaultMessageListenerContainer.java +++ b/spring-jms/src/main/java/org/springframework/jms/listener/DefaultMessageListenerContainer.java @@ -99,13 +99,6 @@ * number of 1 consumer, otherwise you'd receive the same message multiple times on * the same node. * - *

Note: Don't use Spring's {@link org.springframework.jms.connection.CachingConnectionFactory} - * in combination with dynamic scaling. Ideally, don't use it with a message - * listener container at all, since it is generally preferable to let the - * listener container itself handle appropriate caching within its lifecycle. - * Also, stopping and restarting a listener container will only work with an - * independent, locally cached Connection - not with an externally cached one. - * *

It is strongly recommended to either set {@link #setSessionTransacted * "sessionTransacted"} to "true" or specify an external {@link #setTransactionManager * "transactionManager"}. See the {@link AbstractMessageListenerContainer} @@ -419,6 +412,10 @@ public final int getMaxConcurrentConsumers() { * tasks allow thread pools to control the scheduling. Hence, thread * pools will usually prefer short-lived tasks. *

This setting can be modified at runtime, for example through JMX. + *

Using a CachingConnectionFactory in conjunction with a DefaultMessageListenerContainer + * that implements scaling using maxMessagePerTask can result in + * JMS messages delivered to cached consumers that are no longer attached + * to the DefaultMessageListenerContainer. * @see #setTaskExecutor * @see #setReceiveTimeout * @see org.springframework.scheduling.SchedulingTaskExecutor#prefersShortLivedTasks()