JMS dequeuing with JBoss does not seem to respect priority...

[Luca Zitto]

Hi guys,
I have the following situation on a queue. I have posted 6 messages with priority 0 and 6 with priority 5. All of them have attribute JMS_JBOSS_SCHEDULED_DELIVERY set with the same timestamp. I attach extract from JMX Console below:
Given this situation, I would expect all priority 5 messages to be delivered first, and then all priority 0s. What actually happens is that JBoss delivers first one priority 0 message, then all priority 5 and then all other priority 0s. Does anybody understand why?
Thanks


[org.jboss.mq.SpyObjectMessage {
Header {
jmsDestination : QUEUE.dlSendingMessageRelay-mdb
jmsDeliveryMode : 2
jmsExpiration : 0
jmsPriority : 0
jmsMessageID : ID:45-13173127338854
jmsTimeStamp : 1317312733885
jmsCorrelationID: null
jmsReplyTo : null
jmsType : null
jmsRedelivered : false
jmsProperties : {JMS_JBOSS_SCHEDULED_DELIVERY=1317313200000, JMS_JBOSS_REDELIVERY_LIMIT=0}
jmsPropReadWrite: false
msgReadOnly : true
producerClientId: ID:45
}
}, org.jboss.mq.SpyObjectMessage {
Header {
jmsDestination : QUEUE.dlSendingMessageRelay-mdb
jmsDeliveryMode : 2
jmsExpiration : 0
jmsPriority : 0
jmsMessageID : ID:45-13173127348805
jmsTimeStamp : 1317312734880
jmsCorrelationID: null
jmsReplyTo : null
jmsType : null
jmsRedelivered : false
jmsProperties : {JMS_JBOSS_SCHEDULED_DELIVERY=1317313200000, JMS_JBOSS_REDELIVERY_LIMIT=0}
jmsPropReadWrite: false
msgReadOnly : true
producerClientId: ID:45
}
}, org.jboss.mq.SpyObjectMessage {
Header {
jmsDestination : QUEUE.dlSendingMessageRelay-mdb
jmsDeliveryMode : 2
jmsExpiration : 0
jmsPriority : 0
jmsMessageID : ID:45-13173127656089
jmsTimeStamp : 1317312765608
jmsCorrelationID: null
jmsReplyTo : null
jmsType : null
jmsRedelivered : false
jmsProperties : {JMS_JBOSS_SCHEDULED_DELIVERY=1317313200000, JMS_JBOSS_REDELIVERY_LIMIT=0}
jmsPropReadWrite: false
msgReadOnly : true
producerClientId: ID:45
}
}, org.jboss.mq.SpyObjectMessage {
Header {
jmsDestination : QUEUE.dlSendingMessageRelay-mdb
jmsDeliveryMode : 2
jmsExpiration : 0
jmsPriority : 0
jmsMessageID : ID:45-131731276661010
jmsTimeStamp : 1317312766610
jmsCorrelationID: null
jmsReplyTo : null
jmsType : null
jmsRedelivered : false
jmsProperties : {JMS_JBOSS_SCHEDULED_DELIVERY=1317313200000, JMS_JBOSS_REDELIVERY_LIMIT=0}
jmsPropReadWrite: false
msgReadOnly : true
producerClientId: ID:45
}
}, org.jboss.mq.SpyObjectMessage {
Header {
jmsDestination : QUEUE.dlSendingMessageRelay-mdb
jmsDeliveryMode : 2
jmsExpiration : 0
jmsPriority : 0
jmsMessageID : ID:45-131731279543914
jmsTimeStamp : 1317312795439
jmsCorrelationID: null
jmsReplyTo : null
jmsType : null
jmsRedelivered : false
jmsProperties : {JMS_JBOSS_SCHEDULED_DELIVERY=1317313200000, JMS_JBOSS_REDELIVERY_LIMIT=0}
jmsPropReadWrite: false
msgReadOnly : true
producerClientId: ID:45
}
}, org.jboss.mq.SpyObjectMessage {
Header {
jmsDestination : QUEUE.dlSendingMessageRelay-mdb
jmsDeliveryMode : 2
jmsExpiration : 0
jmsPriority : 0
jmsMessageID : ID:45-131731279644015
jmsTimeStamp : 1317312796440
jmsCorrelationID: null
jmsReplyTo : null
jmsType : null
jmsRedelivered : false
jmsProperties : {JMS_JBOSS_SCHEDULED_DELIVERY=1317313200000, JMS_JBOSS_REDELIVERY_LIMIT=0}
jmsPropReadWrite: false
msgReadOnly : true
producerClientId: ID:45
}
}, org.jboss.mq.SpyObjectMessage {
Header {
jmsDestination : QUEUE.dlSendingMessageRelay-mdb
jmsDeliveryMode : 2
jmsExpiration : 0
jmsPriority : 5
jmsMessageID : ID:45-131731289066619
jmsTimeStamp : 1317312890666
jmsCorrelationID: null
jmsReplyTo : null
jmsType : null
jmsRedelivered : false
jmsProperties : {JMS_JBOSS_SCHEDULED_DELIVERY=1317313200000, JMS_JBOSS_REDELIVERY_LIMIT=0}
jmsPropReadWrite: false
msgReadOnly : true
producerClientId: ID:45
}
}, org.jboss.mq.SpyObjectMessage {
Header {
jmsDestination : QUEUE.dlSendingMessageRelay-mdb
jmsDeliveryMode : 2
jmsExpiration : 0
jmsPriority : 5
jmsMessageID : ID:45-131731289167020
jmsTimeStamp : 1317312891670
jmsCorrelationID: null
jmsReplyTo : null
jmsType : null
jmsRedelivered : false
jmsProperties : {JMS_JBOSS_SCHEDULED_DELIVERY=1317313200000, JMS_JBOSS_REDELIVERY_LIMIT=0}
jmsPropReadWrite: false
msgReadOnly : true
producerClientId: ID:45
}
}, org.jboss.mq.SpyObjectMessage {
Header {
jmsDestination : QUEUE.dlSendingMessageRelay-mdb
jmsDeliveryMode : 2
jmsExpiration : 0
jmsPriority : 5
jmsMessageID : ID:45-131731294011424
jmsTimeStamp : 1317312940114
jmsCorrelationID: null
jmsReplyTo : null
jmsType : null
jmsRedelivered : false
jmsProperties : {JMS_JBOSS_SCHEDULED_DELIVERY=1317313200000, JMS_JBOSS_REDELIVERY_LIMIT=0}
jmsPropReadWrite: false
msgReadOnly : true
producerClientId: ID:45
}
}, org.jboss.mq.SpyObjectMessage {
Header {
jmsDestination : QUEUE.dlSendingMessageRelay-mdb
jmsDeliveryMode : 2
jmsExpiration : 0
jmsPriority : 5
jmsMessageID : ID:45-131731294112025
jmsTimeStamp : 1317312941120
jmsCorrelationID: null
jmsReplyTo : null
jmsType : null
jmsRedelivered : false
jmsProperties : {JMS_JBOSS_SCHEDULED_DELIVERY=1317313200000, JMS_JBOSS_REDELIVERY_LIMIT=0}
jmsPropReadWrite: false
msgReadOnly : true
producerClientId: ID:45
}
}, org.jboss.mq.SpyObjectMessage {
Header {
jmsDestination : QUEUE.dlSendingMessageRelay-mdb
jmsDeliveryMode : 2
jmsExpiration : 0
jmsPriority : 5
jmsMessageID : ID:45-131731297156429
jmsTimeStamp : 1317312971564
jmsCorrelationID: null
jmsReplyTo : null
jmsType : null
jmsRedelivered : false
jmsProperties : {JMS_JBOSS_SCHEDULED_DELIVERY=1317313200000, JMS_JBOSS_REDELIVERY_LIMIT=0}
jmsPropReadWrite: false
msgReadOnly : true
producerClientId: ID:45
}
}, org.jboss.mq.SpyObjectMessage {
Header {
jmsDestination : QUEUE.dlSendingMessageRelay-mdb
jmsDeliveryMode : 2
jmsExpiration : 0
jmsPriority : 5
jmsMessageID : ID:45-131731297257030
jmsTimeStamp : 1317312972570
jmsCorrelationID: null
jmsReplyTo : null
jmsType : null
jmsRedelivered : false
jmsProperties : {JMS_JBOSS_SCHEDULED_DELIVERY=1317313200000, JMS_JBOSS_REDELIVERY_LIMIT=0}
jmsPropReadWrite: false
msgReadOnly : true
producerClientId: ID:45
}
}]

[Ove Lindström]

Yes, this sounds strange...

My best guess is that the JMS-handler actually finds time to send the first 0-message while the rest of the 0 and 5 messages are handled. But that is a wild guess.

What happens if you "zebra-send" the messages? (5,0,5,0,5,0,5,0...) Shouldn't matter.

[Luca Zitto]

Thanks for your reply Ove,

What do you mean exactly? with "the JMS-handler actually finds time to send the first 0-message"? they are not sent immediately, in that case I would understand this behaviour... they are all postponed to a specific time (let's say 17:00) which is identical for all messages. From the monitor you can see that all messages are scheduled for exactly the same time... I have the impression that JBoss delivers the first one and only AFTER the first one applies priority, but of course I could be wrong...

"What happens if you "zebra-send" the messages? (5,0,5,0,5,0,5,0...) Shouldn't matter."
This way works but 0,5,0,5... etc still presents the same problem as 0 is the first one stored in the queue...

[ntumba lobo]

In JMS the message priority property is not an absolute rule to follow but more an indication for the JMS provider to process the messages.
The JMS provider will try to process the message by priority by it is not guaranted.

This is explained in the JEE 5 tutorial

[Luca Zitto]

Thanks, so I guess I should not worry about it...