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. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3981251#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...