We are using ThreadPoolExecutor in our JMS consumer and injecting it into a DefaultMessageListenerContainer. I expect this to be running concurrent threads for many messages
After going through the ThreadPoolTaskExecutor code in Spring and reading the Java docs for ThreadPoolTaskExecutor I think this is the answer:
Unbounded queues. Using an unbounded queue (for example a LinkedBlockingQueue without a predefined capacity) will cause new tasks to be queued in cases where all corePoolSize threads are busy. Thus, no more than corePoolSize threads will ever be created. (And the value of the maximumPoolSize therefore doesn't have any effect.)
In our configuration above, we were using the LinkedBlockingQueue by default and our corePoolSize is 1. This is why the maximumPoolSize won't have any effect.