【问题标题】:Spring JMS timeout expiration during consumption from WebSphere MQ queue从 WebSphere MQ 队列消费期间 Spring JMS 超时到期
【发布时间】:2013-12-27 17:46:31
【问题描述】:

我有一个基于 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。

我肯定会设置一个更高的超时值。

【问题讨论】:

    标签: timeout ibm-mq spring-jms


    【解决方案1】:

    超时不是Spring处理的,是在vendor JMS库中处理的...return consumer.receive(timeout).

    当消息到达队列时,代理将消息“推送”给消费者,但是,是的,传输大消息需要有限的时间,而且consumer.receive() 操作肯定有可能超时(可能重复) 直到消息完全传输。

    实际处理由供应商代码决定,但我怀疑是否会阻止接收,因为消息正在传输过程中。

    因此,将消息放入一个队列并不是通知消息在另一个队列中可用的可靠方法。

    考虑只从真正的队列接收(或使用消息驱动的方法而不是 JmsTemplate)。

    【讨论】:

      猜你喜欢
      • 2012-08-27
      • 1970-01-01
      • 2014-04-19
      • 2019-06-16
      • 2013-01-09
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多