MQ selective dequeue speed is sometimes woeful

Question

I have a process that uses JMSTemplate to selectively dequeue from an MQ queue based on JMS header values.

When the dequeue query matches messages at the front of the queue, the dequeue rate is approximately 60-70 msg/second. However, when the query matches messages only 50, 100 or 200 messages deep the dequeue rate drops to 1 msg / 3-4 seconds.

The fast dequeue query is ThreadId='24' or ThreadId='PRIMARY'. The slow dequeue query is ThreadId='24'.

The real reason for the slow processing times might be something else, but I observe the change in processing times with nothing more than the change in deselect query.

I suspect this processing speed is not usual. What could possibly be going wrong?

Answer 1

Querying deep queues by headers is not really recommended as the headers are not indexed. This might be the issue. Queries on CorrelationId and MessageId (if they are on the format 'ID:48-hex-digits') will be indexed and are very quick (~1ms / query on very deep queues, depending on setup).

We faced this issue as well and choose to encode a correlation identifier in the correlation id header instead of in JMS string properties (MQRFH2/usr) headers.

This was on MQ 7.0