This is the simplest form of a message listener container.
It creates a fixed number of JMS Sessions to invoke the listener,
not allowing for dynamic adaptation to runtime demands. Its main
advantage is its low level of complexity and the minimum requirements
on the JMS provider: Not even the ServerSessionPool facility is required.

For a different style of MessageListener handling, through looped
MessageConsumer.receive() calls that also allow for
transactional reception of messages (registering them with XA transactions),
see DefaultMessageListenerContainer.

setConcurrentConsumers

public void setConcurrentConsumers(int concurrentConsumers)

Specify the number of concurrent consumers to create. Default is 1.

Raising the number of concurrent consumers is recommendable in order
to scale the consumption of messages coming in from a queue. However,
note that any ordering guarantees are lost once multiple consumers are
registered. In general, stick with 1 consumer for low-volume queues.

Do not raise the number of concurrent consumers for a topic.
This would lead to concurrent consumption of the same message,
which is hardly ever desirable.

setTaskExecutor

Set the Spring TaskExecutor to use for executing the listener once
a message has been received by the provider.

Default is none, that is, to run in the JMS provider's own receive thread,
blocking the provider's receive endpoint while executing the listener.

Specify a TaskExecutor for executing the listener in a different thread,
rather than blocking the JMS provider, usually integrating with an existing
thread pool. This allows to keep the number of concurrent consumers low (1)
while still processing messages concurrently (decoupled from receiving!).

NOTE: Specifying a TaskExecutor for listener execution affects
acknowledgement semantics. Messages will then always get acknowledged
before listener execution, with the underlying Session immediately reused
for receiving the next message. Using this in combination with a transacted
session or with client acknowledgement will lead to unspecified results!

NOTE: Concurrent listener execution via a TaskExecutor will lead
to concurrent processing of messages that have been received by the same
underlying Session. As a consequence, it is not recommended to use
this setting with a SessionAwareMessageListener, at least not
if the latter performs actual work on the given Session. A standard
MessageListener will work fine, in general.