It sounds like it could be a bug, though it might not be. Assuming you can reproduce this in a test environment, you should try attaching a debugger to the broker, setting breakpoints, and stepping through the relevant code. AbstractSubscription.matches() and Queue.doAcutalDispatch() seem like good places to start with your breakpoints, though I haven't stepped through this particular code before so I'm just guessing.
Also, does this happen when there are only a few messages in the queue? Or does it only happen when there are lots of Version 2 messages mixed in with the Version 1 messages? And does it fix itself when the Version2 consumer comes back online, or are there still unprocessed messages when both consumers are online? I've got a vague memory that in earlier versions of ActiveMQ, there was a limit to how many messages could be in the cursor to be dispatched at any one time and that messages not in the cursor weren't considered for dispatching (so only the first N messages in the queue could be processed, and if all of them were Version 2 messages, they could block any Version 1 messages from being blocked until the Version 1 consumer came online and cleared some of them out). I may be misremembering, and if not there may have been changes in the behavior since those discussions, but if this is still how the broker works, then it could explain messages being blocked while the Version 2 consumer is offline but getting processed once all consumers are back online. On Tue, Nov 18, 2014 at 1:58 PM, juanmanuel.romeraferrio < juanmanuel.romerafer...@gmail.com> wrote: > I'm using version 5.10.0 > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Message-Selector-or-Composite-Destinations-tp4687564p4687673.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
