Also, if your consumers can't process all of the messages before the low-priority ones age off, then you very clearly need more consumers, not priority selectors. Selecting on priority as you've done for the same number of consumers will at best result in the same number of messages consumed (and some messages aging off, some of which will now be normal-priority messages, whereas without selectors they would only be low-priority messages), and at worst you will have fewer messages consumed (because there will probably be periods of time when there are no messages of a given priority, when those consumers will sit idle). If you can't consume all your messages before messages age off, you need more consumers.
Tim On Dec 15, 2015 6:58 AM, "Tim Bain" <tb...@alumni.duke.edu> wrote: > You get all the things you described by continuing to use > policy.setPrioritizedMessages(true) and not having selectors on priority. > Normal-priority messages are still processed before low-priority messages > when both are waiting, and messages in a group are still processed one at a > time. But you now have more consumers who can more quickly work on > normal-priority messages to get through them quickly, and more consumers > who can work on low-priority messages if you're lucky enough to get through > all the normal-priority ones, since all consumers are now allowed to > consume all messages. Plus you no longer have the problem that made you > ask for help in the first place, which is the goal anyway. > > What's the cost? If there are no normal-priority messages in the queue > (so all consumers are consuming low-priority messages) when a > normal-priority message arrives, there is no longer a dedicated consumer > sitting idle who can start processing it immediately, and you have to wait > for the consumer for that message group to finish its current message > before it picks up the new message. But that seems like a perfectly > acceptable downside in light of all the advantages, given that you haven't > said that low-priority messages take an unreasonable amount of time to > process, especially since your current implementation is broken anyway. > > Tim > On Dec 14, 2015 11:34 AM, "artnaseef" <a...@artnaseef.com> wrote: > >> To acheive the split between "high priority" and "low priority" without >> starving the low-priority messages, I recommend: >> >> 1. use separate queues to split the priorities >> 2. either use dedicated consumers for the low priorities that do not take >> resources away from the higher priorities, or use some form of simple >> heuristic to choose when to process the same (e.g. after processing 10 >> high-priority messages, process 1 low-priority message) >> >> The use of a heuristic will be important to allow the balance between >> starving low-priority messages and delaying high-priority ones. >> >> Messaging features, such as priority queueing, are limited and not likely >> to >> give you the desired results. >> >> BTW, I may have missed it - why use message groups? Is messaging order >> important? >> >> >> >> -- >> View this message in context: >> http://activemq.2283324.n4.nabble.com/Selective-consuming-of-priority-messages-with-message-groups-tp4704813p4704938.html >> Sent from the ActiveMQ - User mailing list archive at Nabble.com. >> >
