I had thought that once the message cursor became full of messages for the other selector (because there's only one cursor for a given destination), no more messages could be paged in till some of those others were consumed, but that might not be right (and I'm curious to hear what your code inspection turns up).
If I'm right about all of that, maybe it would be possible to have one cursor per consumer to change this behavior, though that get into complications about how you ensure that a new consumer who might match messages in several consumers' cursors consume available messages in order. If nothing else, there would be some synchronization that would have to be done carefully to make sure a given message is consumed in order once and only once. So maybe there's a better solution than one cursor per consumer... On Jan 30, 2015 4:16 PM, "artnaseef" <a...@artnaseef.com> wrote: > 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. >
