DMLC vs SMLC in case of lots of queues/listeners

[EdwinDhondt]

DefaultMessageListenerContainer = polling mechanism = one polling receive() thread per configured listener.
SimpleMessageListenerContainer => push mechanism = only a thread in case messages arrive.

Let's say I have a production environment with 10 queues.
Let's say a message is to be consumed once-and-only-once.

I could configure 1 DMLC with 10 listeners (one per queue).
But that would mean that 10 threads are always in use, even when no message are to be processed.
Is that a correct conclusion ?
If so, doesn't that imply that using DMLC is very inefficient due to the fact so many threads are doing nothing ?

Wouldn't a SMLC approach be better in that respect ?
But then will SMLC work with JTA transaction manager and XA transactions ?
If not, what are my options if I want to use threads efficiently and at the same time I want to use JTA txn manager and XA ?

[Mark Fisher]

It sounds like you should explore the "concurrent-consumers" option on DMLC. You can specify a range such as "5-25". In that case, the "core" thread pool contains 5 but the pool can grow up to 25 when needed. Based on the idle execution limit, the pool can shrink back down to the core size after activity decreases.

[EdwinDhondt]

But if I have e.g. 10 different queues, then I need 10 listeners isn't it ?
Doesn't that mean then that I will have at least one DMLC listener-container with concurrency 1, having 10 listener elements (one for each of the 10 queues) ? Doesn't that imply then I'll have at a minimum 10 threads constantly polling ?
Or am I missing something ?

[Gary Russell]

Yes; you need one thread per queue. The concurrency controls allow you to increase the threads per queue on an as-needed basis.

The SMLC does not support JTA/XA.