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#3981251

Reply to the post : 
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3981251
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user

Reply via email to