我有一个基于Spring JMS的客户端,它异步地侦听QUEUE1上的“触发器”,它们表明有一条消息准备好在另一个队列上消耗,QUEUE2。
QUEUE2的消耗是通过JmsTemplate类完成的,配置如下:
<bean id="jmsTemplate" class="org.springframework.jms.core.JmsTemplate">
<constructor-arg ref="gpyConnectionFactory" />
<property name="destinationResolver" ref="jndiDestinationResolver" />
<property name="receiveTimeout" value="100" />
</bean>
注意一点点receiveTimeout。在负责此申请之前,这个价值已经是这样了 现在,我注意到有时,特别是当QUEUE2包含相对较大的消息时, 致电
jmsTemplate.receiveSelectedAndConvert(destinationName, mqSelector);
检索一个NULL对象,因此超时可能会到期!
据我所知,正如JMS规范所述(如果我错了,请纠正我),只有队列中没有消息可用时,超时才会到期。 当前场景让我相信,由于消息大小以及由于确实存在该队列的消息,超时会到期,因为消费者没有足够的时间来阅读整个大消息。 一切皆有可能吗?
提供者是WebSphere MQ。
我肯定会设置更高的超时值。
答案 0 :(得分:0)
Spring不处理超时,它在供应商JMS库中处理...... return consumer.receive(timeout)
。
当消息到达队列时,代理将消息“推送”给消费者但是,是的,传输大消息需要一段有限的时间,consumer.receive()
操作当然有可能超时(可能反复)直到消息完全转移。
由供应商代码来实际进行处理,但我怀疑是否会阻止接收,因为正在传输消息。
因此,将消息放在一个队列中并不是通知另一个队列中的消息可用的可靠方法。
考虑从真实队列接收(或使用消息驱动方法而不是JmsTemplate)。