title: Oracle AQ using JMS and JMSXGroupID does not result in 'sticky' consumers
body: <p>Apache ActiveMQ Artemis uses <code>JMSXGroupId</code> to implement 'sticky' consumer sessions. Messages enqueued with the same <code>JMSXGroupId</code> are sent to the same consumer, in FIFO, single threaded. This does however allow for multiple threads to process unique <code>JMSXGroupId</code> groups concurrently - which is perfect - see below:</p>
  <pre><code>16:46:42.451 [Thread-4] INFO Log - This is Message 30 In JMSXGroup: Group C | To Thread Thread-4
  16:46:42.451 [Thread-3] INFO Log - This is Message 283 In JMSXGroup: Group B | To Thread Thread-3
  16:46:42.451 [Thread-3] INFO Log - This is Message 284 In JMSXGroup: Group B | To Thread Thread-3
  16:46:42.451 [Thread-4] INFO Log - This is Message 31 In JMSXGroup: Group C | To Thread Thread-4
  16:46:42.452 [Thread-4] INFO Log - This is Message 32 In JMSXGroup: Group C | To Thread Thread-4
  16:46:42.452 [Thread-3] INFO Log - This is Message 285 In JMSXGroup: Group B | To Thread Thread-3
  </code></pre>
  <p>Oracle AQ and Amazon SQS do not exhibit the same 'sticky' consumer behaviour. I cannot find anything specific in the JMS Specification other than <code>JMSXGroupId</code> is used to group related messages together.</p>
  <p>My expectation was that all JMS Consumers would exhibit this 'sticky' behaviour when <code>JMSXGroupId</code> was set but this does not appear to be the case.</p>
  <p>Has anyone managed to achieve this behaviour with Oracle AQ / SQS solely by setting JMSXGroupId? Or is the intention of <code>JMSXGroupId</code> to allow the <code>consumer</code> to use a <code>selector</code> when dequeuing? That does not seem as though it would scale as it would need to be discerned at runtime, whereas the ActiveMQ implementation clearly does.</p>