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
try this:
<bean id="threadPoolTaskExecutor"
class="org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor">
<property name="corePoolSize" value="10" />
<property name="maxPoolSize" value="25" />
<property name="queueCapacity" value="30" />
</bean>
I think chosen answer is wrong. IIRC, the way ThreadPoolTaskExecutor (eventually ThreadPoolExecutor in JDK ) working is
So the problem here I think is, either 1) your consumer is fast enough or 2) you are stacking requests too slowly, so one thread you specify with corePoolSize was enough to process new incoming requests + queued task without allowing ThreadPoolTaskExecutor to create new threads. I'm pretty sure if you push it harder or set queue's capacity with small number ( like 5~10 ), you'll be able to see the number of threads is increasing.
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.
change the corePoolSize to 10, then you will get 10 threads run concurrently. Read the javadoc on java.util.concurrent.ThreadPoolExecutor which is the backbone of the spring ThreadPoolTaskExecutor, then you will have better understand how to config the corePoolSize and maxPoolSize and queueCapacity