Provide a configuration property for JMS listener container's max messages per task

[apinske]

• Spring Boot 2.7.18
• Default DMLC JMS Listener Config
• the active listener threads do not automatically scale down (using default config)
• taken code path org.springframework.jms.listener.DefaultMessageListenerContainer.AsyncMessageListenerInvoker.executeOngoingLoop()
• there is no default mechanism to change the path taken, i.e. no spring.jms.listener.max-messages-per-task property)

1. I don't understand the need for the two code paths in spring-framework in the first place
2. but since they are there, somewhere this problem should be addressed
   1. either fix spring-framework to also scale down in the executeOngoingLoop-Case
   2. in spring-boot use the other code-path (e.g. set maxMessagesPerTask=1); or at least make it configurable through spring-boot

Find a sample here: https://github.com/apinske/playground-mq/tree/scaling

[wilkinsona]

There's no configuration property for maxMessagesPerTask, but you can configure it by defining your own DefaultMessageListenerContainerFactory and using DefaultJmsListenerContainerFactoryConfigurer to apply Boot's defaults:

@Bean
DefaultJmsListenerContainerFactory jmsListenerContainerFactory(
		DefaultJmsListenerContainerFactoryConfigurer configurer, ConnectionFactory connectionFactory) {
	DefaultJmsListenerContainerFactory factory = new DefaultJmsListenerContainerFactory();
	configurer.configure(factory, connectionFactory);
	factory.setMaxMessagesPerTask(1);
	return factory;
}

We could consider adding a configuration property for this if we feel that it would be generally useful.

Your other points about Spring Framework will have to be addressed by the Framework team. Please open an issue with them for their consideration. We'll keep this issue in Boot's tracker to consider a configuration property for the maximum messages per task.

[apinske]

Might I offer a suggestion: You could make JmsListenerContainerFactoryConfigurer an interface, and discover all beans, like other places of spring-boot do. Then it would be easier to customise.

[snicoll]

Closing in favor of PR #42341