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.