Use of multi-threaded message handling

[bjetal]

Issue description

I think the approach of farming message handling out to a thread pool from a single consumer thread is going to cause more problems than it is going to solve.

While I appreciate that it reduces the number of connections to the broker, because it does not fit well with the JMS model which more or less dictates that each consumer handle a single message at a time. In particular:

• Transacted message delivery means nothing when the transaction is committed without the message being handled, which is what is currently happening.
• JMS client acknowledgement by default acknowledges all messages up to and including the message being acknowledged. The multi-threaded approach allows messages to be acknowledged out of order, meaning that an earlier message that fails processing might end being acknowledged when a later message successfully processes.
• Under high message volumes, you can end up in situations where either:
  • The ExecutorService rejects the message handler job submission (which happens when using the "concurrency" setting on the @Queue or @Topic annotation). In many cases this means the application will never see the messages as the other issues noted above cause the messages to be acknowledged.
  • The ExecutorService creates a large backlog of jobs to execute, causing increased memory consumption
  • The ExecutorService creates a huge number of threads to process the messages

While especially the latter can probably be worked around with some careful programming, I think this project may be better off going with a consumer per thread model (which is what the more or less equivalent Spring functionality uses).