title: Best practice for multi-threaded message processing on JMS queues
body: <p>I'm currently adding JMS support to a application-server-like framework. The JMS will be implemented by HornetQ (stand-alone broker, hornetq jars on the servers classpath) but there is neither JBoss nor spring nor anything else that would provide MDBs.</p>
  
  <p>The next step is to add a message listener to a xa queue that would allow for parallel processing of incoming messages. Some messages would init long running tasks, so the basic idea is to spawn worker threads from the <code>onMessage</code> method.</p>
  
  <p>On my long journey through the internet I came across <a href="https://community.jboss.org/message/594586#594586" rel="noreferrer">this discussion</a>, where one of participants mentioned, that he would not do that but use an extra internal queue for the task: the (single threaded) message listener then would simply grab the messages from the inbound queue and create new messages for an internal queue, where at the other end of that internal queue some worker threads fight for the incoming messages. Inbound messages then would be acknowledge once they're "copied" to the internal queue (which is ok for me).</p>
  
  <p>Unfortunatly they don't say <em>why</em> it would be better to not spawn worker threads from the <code>onMessage</code> method - maybe, because the listener would block if all threads from the pool are busy. So I'm looking for pros and cons for the designs decisions:</p>
  
  <ul>
  <li>Start worker threads from the onMessage method of the message listener</li>
  <li>Use an internal queue to "send messages to the worker threads"</li>
  </ul>