tbain98 has the right idea. And that raises an interesting question regarding messages on-disk and not in-memory - I need to review to see how that operates.
Here's how I expect it to work: the consumer with it's exclusive selector will get all pending messages which match its selector regardless of what other messages are unconsumed on the Queue. It would be easy to test the disk case too, like this: * Start a broker with persistence enabled (e.g. KahaDB) * Do not start any consumers * Produce a large number of persistent messages to a queue; split 50/50 between two selectors (10k or 100k should be adequate) * Shutdown the broker * Start the broker back up * Consume with only one selector and confirm it receives all of the matching messages. Now I'm curious and want to review the code. Note this scenario is another one I'll put on my list of reasons that selectors are bad for performance. If the broker has to replay every message in storage to possibly find those that match a single selector every time a new consumer is added, that could lead to some terrible performance scenarios. To the original use-case, can separate queues be used instead? -- View this message in context: http://activemq.2283324.n4.nabble.com/Message-priority-and-message-selector-Active-MQ-version-5-4-tp4690692p4690727.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
