activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <>
Subject Re: Message priority and message selector - Active MQ version 5.4
Date Sat, 31 Jan 2015 04:45:36 GMT
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
On Jan 30, 2015 4:16 PM, "artnaseef" <> 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:
> Sent from the ActiveMQ - User mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message