Spring JMS DMLC消息在重新启动之前未被捕获

时间:2014-10-01 21:59:13

标签: spring jms tibco

我正在使用DMLC来收听Tibco EMS队列(Tomcat)。一段时间后,消息未被传递。重新启动后,将再次传递邮件。我正在使用SingleConnectionFactory。

Connection Factory:
 <bean id="jmsConnectionFactory" class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiTemplate" ref="jndiTemplate" />
    <property name="jndiName"     value="${connectionQueueFactory}" />
    <property name="cache"  value="false"/>
    <property name="lookupOnStartup" value="false"/>
    <property name="proxyInterface" value="javax.jms.ConnectionFactory"/>
 </bean>

Authenticated Connection Factory:
 <bean id="authenticationConnectionFactory"
    class="com.my.service.AuthenticationConnectionFactory"> <-- extends SingleConnectionFactory
    <property name="targetConnectionFactory" ref="jmsConnectionFactory" />
    <property name="username" value="${userName}" />
    <property name="password" value="${password}" />
    <property name="sessionCacheSize" value="1"/>
 </bean>

Destination Resolver:
<bean id="destinationResolver" class="org.springframework.jms.support.destination.JndiDestinationResolver">
    <property name="jndiTemplate" ref="jndiTemplate" />
   <property name="cache" value="true"/>
</bean>

Container:
<jms:listener-container concurrency="10-15" container-type="default" 
                        connection-factory="simpleAuthenticationConnectionFactory" 
                        destination-type="queue"
                        cache="consumer"
                        prefetch="1"
                        destination-resolver="destinationResolver"
                        acknowledge="transacted">
                 ..... listeners.....
  </jms:listener-container>

谢谢。

1 个答案:

答案 0 :(得分:0)

如果在处理期间抛出异常,

acknowledge="transacted"将无法确认消息,这可能导致此行为,因为EMS守护程序认为您的应用程序仍在忙于处理已传递但未确认的消息。

但是transacted也是唯一一种保证在发生异常时重新传递的确认模式。

这意味着你不能抛出异常,除非你的应用程序正在关闭,这可能是一个真正的痛苦。我已经在文章The Chain of Custody Problem中涵盖了各种选项。简短版本是:

  1. 弃掉邮件并忽略错误;
  2. 将消息(和/或错误)发送到错误日志或队列,由人员监控;
  3. 将消息(和/或错误)发送到错误队列,该队列由发送应用程序处理。
  4. 所有这些选项都存在问题,这就是Fire-and-Forget messaging sucks的原因,但在您的情况下,您可能会发现选项2是最实用的。