Changing to an alternative internal selector algorithm on the reply queue fixes the problem. Since our application does not rely on the message priority, we can live with the following workaround:
This is the stack trace where JMS MQv6 Solaris 10 hangs for up to 5s using selector JMSCorrelationID like ...% if there is at least one message in the queue with an empty CorrelationID.
Since migration from MQv5.3 to MQv6 Solaris10 I observe 5s delays in queueReceiver.receive(timeoutMs) having a queueReceiver with selector, e.g. JMSCorrelationID like ...%. The QCF options setPollingI ...