title: One slow ActiveMQ consumer causing other consumers to be slow
body: <p>I'm looking for help regarding a strange issue where a slow consumer on a queue causes all the other consumers on the same queue to start consuming messages at 30 second intervals. That is all consumers but the slow one don't consumer messages as fast as they can, instead they wait for some magical 30s barrier before consuming.</p>
  
  <p>The basic flow of my application goes like this:</p>
  
  <ol>
  <li>a number of producers place messages onto a single queue. Messages can have different JMSXGroupIDs</li>
  <li>a number of consumers listen to messages on that single queue</li>
  <li>as standard practice the JMSXGroupIDs get distributed across the consumers</li>
  <li>at some point one of the consumers becomes slow and can't process messages very quickly</li>
  <li>the slow consumer ends up filling its prefetch buffer on the broker and AMQ recognises that it is slow (default behaviour)</li>
  <li>at that point - or some 'random' but close time later - all consumers except the slow one start to only consume messages at the same 30s intervals</li>
  <li>if the slow consumer becomes fast again then things very quickly return to normal operation and the 30s barrier goes away</li>
  </ol>
  
  <p>I'm at a loss for what could be causing this issue, or how to fix it, please help. </p>
  
  <p><strong>More background and findings</strong></p>
  
  <ul>
  <li>I've managed to reliably reproduce this issue on AMQ 5.8.0, 5.9.0 (where the issue was originally noticed) and 5.9.1, on fresh installs and existing ops-managed installs and on different machines some vm and some not. All linux installs, different OSs and java versions.</li>
  <li>It doesn't appear to be affected by anything prefetch related, that is: changing the prefetch value from 1 to 10 to 1000 didn't stop the issue from happening</li>
  <li>[red herring?] Enabling debug logs on the amq instance shows logs relating to the periodic check for messages that can be expired. The queue doesn't have an expiry policy so I can only think that the scheduled <code>expireMessagesPeriod</code> time is just waking amq up in such a way that it then sends messages to the non-slow consumers.</li>
  <li>If the 30s mode is entered then left then entered again the seconds-past-the-minute time is always the same, for example 14s and 44s past the minute. This is true across all consumers and all machines hosting those consumers. Those barrier points do change after restarts of amq.</li>
  </ul>