This content has been marked as final. Show 2 replies
In our testing, we have found that the consumerFlowLimit implementation will guarantee that you'll receive your messages out of order. What happens is that messages will be put in the consumer buffer and they won't be available for round-robin delivery to the other consumers (even if they are idle). I'd recommend setting the consumerFlowLimit=1 which minimizes the impact of this, but every other message will still be out of order (ie consumer #1 grabs messages 1&2, consumer #2 grabs messages 3&4, etc; so that they will process 1&3 together, and 2&4 together. I consider this a very serious bug of openMQ and wish we could disable the consumerFlowBuffer all together to get guaranteed processing order from the queue.
Edited by: Pancetta on Jun 24, 2010 9:33 AM
1). The issue of prefetch by client runtime on Consumer.receive() with imqConsumerFlowLimit=1, CR6727929, has been fixed in 4.5, available in build12 - by setting a new connection factory property imqConsumerFlowLimitPrefetch=false
2). JMS specification does not specify the order of message delivery across destinations (JMS 1.1 spec 184.108.40.206) or to multiple QueueReceivers (JMS 1.1 spec 4.4.9). For GlassFish Message Queue, message delivery order in these situations depends on several runtime factors, e.g. flow control settings, processing speed, ...