I have some additional notes about some other side effects I've encountered that I can attribute to this same bug. Just posting them here in case anyone else not running 5.6.0 yet is running into them and trying to figure out what is going on.
I noticed that, when using a temporary destination and then closing a connection and subsequently receiving the "Consumer is consuming..." exception, the consumer for the queue I closed a connection to was left dangling.
That is, I start up my application with X amount of consumers and look at the queue via JMX under org.apache.activemq->myBrokerName->Queue->myQueuName->Attributes->Subscriptions
and see X amount subscriptions to that queue as expected. I then instruct my application to shut down Y amount of consumers, and the Subscriptions count remains at X instead of the expected value of X - Y = Z.
If I disable the portion of my application that uses the temporary queue, then no exceptions happen, and the above shutdown test does cause the Subscriptions count to drop to Z accordingly.
What's worse is that it's not just excess JMX ObjectNames left behind, but the actual consumer subscriptions they relate to are also still there and registered with ActiveMQ / bound to that queue as MessageListeners. That can be verified via JMX as well, under org.apache.activemq->myBrokerName->Subscription->Non-Durable->Queue->myQueueName.
So what happens next is...
I then trigger my application to produce a bunch of messages into myQueueName. Most of them are consumed by the remaining Z consumers, but a certain number of them just get stuck in the queue. And not just any number, but precisely the number Y * prefetchSize.
If I restart my entire application the messages then get re-delivered to the fresh consumers and flushed out of myQueueName. That is, unless I don't get to it in time, at which point they expire and end up in the DLQ instead.
Again, disabling the use of temporary qeueus avoids this issue. The problem, of course, is that I need the temps for proper app functionality!
I also tested this scenario with the current 5.6.0-SNAPSHOT and can confirm that it does indeed resolve the issue.