Spring JMS timeout expiration during consumption from WebSphere MQ queue

Question

i have a Spring JMS based client that asynchronously listens for "triggers" on QUEUE1, they indicate that there is a message ready to be consumed on another queue, QUEUE2.

Consumption on QUEUE2 is done with JmsTemplate class, configured as follows:

<bean id="jmsTemplate" class="org.springframework.jms.core.JmsTemplate">
        <constructor-arg ref="gpyConnectionFactory" />
        <property name="destinationResolver" ref="jndiDestinationResolver" />
        <property name="receiveTimeout" value="100" />
    </bean>

Notice the little receiveTimeout. This value was already so, before taking charge of this application.
NOW, I noticed that sometimes, specifically when QUEUE2 contains a relative big message, a call to

jmsTemplate.receiveSelectedAndConvert(destinationName, mqSelector);

retrieves a NULL object, so it is likely that timeout expires!

As far as I know, as JMS spec states (correct me if I'm wrong) timeout would expire only if no message is available on the queue. The current scenario makes me believe that due to message size and due to the fact that for sure there is a message of that queue, the timeout expires because the consumer doesn't have enough time to read the whole big message. Is it all that possible?

The provider is WebSphere MQ.

For sure I will set an higher timeout value.

Answer 1

The timeout is not processed by Spring, it is handled in the vendor JMS library...return consumer.receive(timeout).

The broker "pushes" the message to the consumer when it arrives in the queue but, yes, it will take a finite time to transfer a large message and it is certainly possible for the consumer.receive() operation to timeout (maybe repeatedly) until the message is fully transferred.

It's up to the vendor code to actually do the processing, but I would doubt any would block a receive because a message is in the process of being transferred.

So, putting a message in one queue is not a reliable way to notify that a message is available in another queue.

Consider just receiving from the real queue (or use a message-driven approach instead of the JmsTemplate).