message priority working jboss messaging 1.0.1???

[markusw]

Hi,

Does the JMS message priority in JBoss Messaging 1.0.1GA have any effect?

I have two senders with code like this:

Queue queue = (Queue) ic.lookup("/queue/testQueue")
connection = cf.createConnection();
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
MessageProducer sender = session.createProducer(queue);
TextMessage message = session.createTextMessage("Hello! ");
sender.send(message, DeliveryMode.PERSISTENT, priority, 0 );

One sender sends out messages with higher priority than the other but the messages with higher priority are NOT delivered first to the sender.
I use JBoss 4.0.5, installed JBoss Messaging 1.0.1 GA and used the generated configuration "messaging" with a Postgres 8.1 database.
When I repeat the same test with the JBoss.mq stack, I clearly see messages with higher priority delivered first to the receiver.

Am I missing something or is there a bug in the jms stack?

Markus

[clebert.suconic]

I see clearly that priorities are taken in consideration.

This is implemented on BasicPrioritizedDeque...


Maybe the message is already consumed when the next message arrives.
I don't think there is a bug... but if you find anything maybe you could write a small testcase showing the problem you're having.

[timfox]

As Clebert has inferred, perhaps the cause is simply that you are consuming messages as fast as you send them, in which case priority is irrelevant.

Priority is only relevant when there are multiple messages on a queue with different priorities and delivery occurs.

If you can replicate this in a simple test case / code example that would be a great help to us.

[markusw]

Ok, let me explain my setup in greater detail:
I have have a OnlineRequestSender sending with priority 9 and a BatchRequestSender sending with default priority (4). I add a timestamp to the message header for rtt measurement. I have a consumer with a controlled message consumption rate of 10 messages per second.

OnlineRequestSender (5 msg/s)--->
 RequestQueue ----> Consumer (10 msg/s)
BatchRequestSender --->


Consumer -----> ResponseQueue ---> ResultReceiver

The OnlineRequestSender sends 5 msg/s thus leaving half of Consumer's capacity to Bulk jobs. The BulkRequestSender sends from time to time several messages (100-10000) in a row to the RequestQueue. The Consumer receives a message, processes it and puts a new message in the response queue (by copying the aforementioned timestamp). The ResultReciver can thus determine round-trip times for each message. The messages are simple TextMessages with text "O" for online and "B" for batch class.
I expected on the ResultReceiver side message ordering like "OBOBOBOB" if the queue is filled with many low-prioritized message.

This is what I see with the JBoss.mq stack. With the JBoss messaging stack I see a lot of B's with occasionally a few O's in a row i.e. BBBBBBBBBBBBBBBBBOOOBBBBBBBBBBBBBBBBBBBB .

So the rtt for prioritized requests is pretty bad.
It seems that the new stack puts the messages into DB, later loads some data in memory and THEN evaluates the message priority. I think the priority should be part of the SQL statement used for selecting messages to be delivered.
I can provide the test case if necessary.

[timfox]

"markusw" wrote:

It seems that the new stack puts the messages into DB, later loads some data in memory and THEN evaluates the message priority. I think the priority should be part of the SQL statement used for selecting messages to be delivered.

The DB has nothing to do with it, delivery order is not evaluated via a SQL statement it is evaluated completely in memory
.

I can provide the test case if necessary.

Please do. Thanks.

[timfox]

By default messages will be prefetched into consumers.

See
http://labs.jboss.com/file-access/default/members/jbossmessaging/freezone/docs/guide-1.0.1.GA/html/configuration.html#conf.connections

So what could be happening is that they are going straight through the queue and ending up in the consumer. And then slowly being consumed from the consumer.

Since your consumer is so slow, you could try setting prefetch to a lower value (like 1).

Prefetch is vital for high peformance consumers.

[markusw]

"timfox" wrote:
By default messages will be prefetched into consumers.

Since your consumer is so slow, you could try setting prefetch to a lower value (like 1).

Prefetch is vital for high peformance consumers.

This improves the situation a bit.
with a prefetch size=10 I saw a burst of 10 high prio msg taking turns with approx. 100 low prio messages like:
BOOOOOOOOBBB.........BBBBBBOOOOOOOOOBBBB..........BBBOOOOOOOO....

with prefetch size=1 I see one or two high prio messages separated by approx. 10 low prio messages.
BOOOBBBBBBBOOBBBBBBBBOOBBBBBBBBOOBBBBBBBB

Still, the rtt for high prio messages is in the order of seconds because of these low prio messages. With just high prio messages the rtt is less than 15msg on my linux box. The jboss.mq stack kept this below 100ms (if I remember correctly) when additional low prio messages where in the queue.

[timfox]

Ok, thanks Markus-

I'm surprised setting the prefetch didn't change things, but will add this as an issue to investigate anyway.

[timfox]

http://jira.jboss.com/jira/browse/JBMESSAGING-628

[hendra_netm]

Hi,

I did this kind of priority test before.
What I did was sending messages with different priority but I stopped the consumer's connection untill queue is filled.

From my test, I got all messages with highest priority first.

I used jboss 4.0.4 and messaging CR5 with postgre 8.1

Hope it helps.

Regards,
Hendra