Contrary to the documentation, setting spring.jms.listener.concurrency alone configures the maximum concurrency#37180
Conversation
Update JMS listener concurrency configuration to set the same minimum and maximum number of consumers when users specify only the minimum using `spring.jms.listener.concurrency` property. Prior to this commit, when using `spring.jms.listener.concurrency` to set the minimum number of consumers without also specifying `spring.jms.listener.max-concurrency` would result in effective concurrency where the actual minimum number of consumers is always 1, while the maximum number of consumers is the value of `spring.jms.listener.concurrency`.
|
Thanks, @vpavic. I'm tempted to rework the properties a little bit as well. Given the
This is tricky due to the clash with the existing
I also wonder if There's no need for any updates to the changes proposed here. I'd like to discuss the above with the team so we can decide if and when to change things. It may be that the changes are made across different releases. |
|
Your If the team decides that's the way forward, I can put together a separate PR for that change as well. |
Update JMS listener concurrency configuration to set the same minimum and maximum number of consumers when users specify only the minimum using `spring.jms.listener.concurrency` property. Prior to this commit, when using `spring.jms.listener.concurrency` to set the minimum number of consumers without also specifying `spring.jms.listener.max-concurrency` would result in effective concurrency where the actual minimum number of consumers is always 1, while the maximum number of consumers is the value of `spring.jms.listener.concurrency`. See gh-37180
|
Thanks very much, @vpavic. |
Update JMS listener concurrency configuration to set the same minimum and maximum number of consumers when users specify only the minimum using
spring.jms.listener.concurrencyproperty.Prior to this commit, when using
spring.jms.listener.concurrencyto set the minimum number of consumers without also specifyingspring.jms.listener.max-concurrencywould result in effective concurrency where the actual minimum number of consumers is always 1, while the maximum number of consumers is the value ofspring.jms.listener.concurrency.This fix results in a breaking change, however the current behavior is simply not aligned with the description of
spring.jms.listener.concurrencyproperty.Also see the javadoc of
DefaultMessageListenerContainer#setConcurrencywhich states: