Message priority on HornetQ 2.2.5

[kapilnikhra]

I am using HornetQ 2.2.5 and sending messages to it with either high ( 9) or LOW (0) priority, with the expecations that all the high priority messages are going to be delivered first and the low  priority are going to be delivered only when all the high priority message have been consumed. But during our testing we noted that  few  of the low priority message are getting delivered before the high priority messages.  While trying to find the issues we saw the following jira issue which talks about a fair priority algorithim.

https://issues.jboss.org/browse/HORNETQ-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

The above might explain the behaviou we are seeing. Tim fox talks about a "pluggable algorithim" for message priority. Is this something that can be configured, or is there some way to get around this, so that we can get a guarneet that HIGH priority messages will be delivered before the LOW priority messages.

[ataylor]

I am using HornetQ 2.2.5 and sending messages to it with either high ( 9) or LOW (0) priority, with the expecations that all the high priority messages are going to be delivered first and the low  priority are going to be delivered only when all the high priority message have been consumed. But during our testing we noted that  few  of the low priority message are getting delivered before the high priority messages.  While trying to find the issues we saw the following jira issue which talks about a fair priority algorithim.

Actually this is the way HornetQ does it, highest priority first, if it isnt then its probably the way your app is consuming. The JIRA is to stop starvation because of this.

[kapilnikhra]

Following is the description of change mentioned by Tim on the JIRA, and as i understand it he is saying that that with this new changes the higher priority messages might not be delivered first.

"

The current message priority strategy is very crude and always delivers higher priority messages first if they exist.

This can cause starvation of lower priority messages.

The algorithm should be improved to prevent starvation.

It may be an idea to make the algorithm pluggable using the strategy pattern.

"

We added 400 messages to a Q with 200 of them as high and rest 200 as low priority. When we started the Q consumer ( org.springframework.jms.listener.DefaultMessageListenerContainer with 10 concurrent consumers)

First 100 messages consumed were all high messages, but out of the next 100 messages only 78 were high priority and rest 22 were low priority and then later on the rest of the 22 high priority messages were delivered with the low priority messages.

[ataylor]

always delivers higher priority messages first

Like I say, High priority messages are *always* delivered first.

We added 400 messages to a Q with 200 of them as high and rest 200 as low priority. When we started the Q consumer ( org.springframework.jms.listener.DefaultMessageListenerContainer with 10 concurrent consumers)

First 100 messages consumed were all high messages, but out of the next 100 messages only 78 were high priority and rest 22 were low priority and then later on the rest of the 22 high priority messages were delivered with the low priority messages.

you can't gaurantee an order when you have multiple consumers, remember messages will be buffered and depending on how they are consumed some consumers may have high prioiry messages still buffered whilst other consumers are starting to consume lower priority messages.

to be honest, the JMS spec doesn't define how this should work so even if they were delivered in a different order it is still spec compliant, you probably shouldn't make your app depend on this.