使用和不使用 Spring JMS 的 AUTO_ACKNOWLEDGEMENT 模式之间的区别
Difference between AUTO_ACKNOWLEDGEMENT mode with and without Spring JMS
我正在尝试了解确认模式在 JMS 中的工作原理。我正在阅读这个来源，它让我非常困惑，因为它与 Spring 的文档所说的相矛盾。
消息来源说一件事：
来自 http://www.javaworld.com/article/2074123/java-web-development/transaction-and-redelivery-in-jms.html
A message is automatically acknowledged when it successfully returns from the receive() method. If the receiver uses the MessageListener interface, the message is automatically acknowledged when it successfully returns from the onMessage() method. If a failure occurs while executing the receive() method or the onMessage() method, the message is automatically redelivered.
来自http://www2.sys-con.com/itsg/virtualcd/Java/archives/0604/chappell/index.html
With AUTO_ACKNOWLEDGE mode the acknowledgment is always the last thing to happen implicitly after the onMessage() handler returns. The client receiving the messages can get finer-grained control over the delivery of guaranteed messages by specifying the CLIENT_ACKNOWLEDGE mode on the consuming session.
Spring 文档说其他事情：
来自 http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/jms/listener/AbstractMessageListenerContainer.html
The listener container offers the following message acknowledgment options:
"sessionAcknowledgeMode"设置为"AUTO_ACKNOWLEDGE"（默认）：监听器执行前自动消息确认；抛出异常时不重新投递。
"sessionAcknowledgeMode"设置为"CLIENT_ACKNOWLEDGE"：监听器执行成功后自动消息确认；抛出异常时不重新投递。
"sessionAcknowledgeMode" 设置为 "DUPS_OK_ACKNOWLEDGE"：侦听器执行期间或之后的惰性消息确认；在抛出异常的情况下可能重新交付。
"sessionTransacted" 设置为 "true"：监听器执行成功后的事务确认；在抛出异常的情况下保证重新投递。
我想知道的是，为什么这些消息来源说的不同？如果一切都是真的那么我怎么知道 how/when 我的消息会被确认？
您错过了抽象容器 javadocs 中的关键短语...
The exact behavior might vary according to the concrete listener container and JMS provider used.
Spring 中最常用的侦听器容器是 DefaultMessageListenerContainer， 表现出这种行为 - 它旨在与事务一起使用（要么本地或外部事务管理器），以便能够回滚已确认的消息。它的侦听器在接收方法之后被调用，因此已经应用了标准的 JMS 自动确认。线程上的任何 JmsTemplate 操作也可以使用相同的会话 - 因此可以成为事务的一部分。
另一方面，SimpleMessageListenerContainer 使用传统的 MessageListener 并表现出标准的 JMS 行为（在 receive() 之前从 Consumer 调用侦听器 returns; 因此异常将停止 ack).
我建议您阅读这些具体实现的 javadoc。从 SMLC...
This is the simplest form of a message listener container. It creates a fixed
number of JMS Sessions to invoke the listener, not allowing for dynamic
adaptation to runtime demands. Its main advantage is its low level of
complexity and the minimum requirements on the JMS provider: Not even the
ServerSessionPool facility is required.
See the AbstractMessageListenerContainer javadoc for details on acknowledge
modes and transaction options.
For a different style of MessageListener handling, through looped
MessageConsumer.receive() calls that also allow for transactional reception of
messages (registering them with XA transactions), see
DefaultMessageListenerContainer.
我将为抽象容器上的文档打开一个 JIRA 问题，因为我知道它可能具有误导性。
我正在尝试了解确认模式在 JMS 中的工作原理。我正在阅读这个来源，它让我非常困惑，因为它与 Spring 的文档所说的相矛盾。
消息来源说一件事： 来自 http://www.javaworld.com/article/2074123/java-web-development/transaction-and-redelivery-in-jms.html
A message is automatically acknowledged when it successfully returns from the receive() method. If the receiver uses the MessageListener interface, the message is automatically acknowledged when it successfully returns from the onMessage() method. If a failure occurs while executing the receive() method or the onMessage() method, the message is automatically redelivered.
来自http://www2.sys-con.com/itsg/virtualcd/Java/archives/0604/chappell/index.html
With AUTO_ACKNOWLEDGE mode the acknowledgment is always the last thing to happen implicitly after the onMessage() handler returns. The client receiving the messages can get finer-grained control over the delivery of guaranteed messages by specifying the CLIENT_ACKNOWLEDGE mode on the consuming session.
Spring 文档说其他事情： 来自 http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/jms/listener/AbstractMessageListenerContainer.html
The listener container offers the following message acknowledgment options:
"sessionAcknowledgeMode"设置为"AUTO_ACKNOWLEDGE"（默认）：监听器执行前自动消息确认；抛出异常时不重新投递。 "sessionAcknowledgeMode"设置为"CLIENT_ACKNOWLEDGE"：监听器执行成功后自动消息确认；抛出异常时不重新投递。 "sessionAcknowledgeMode" 设置为 "DUPS_OK_ACKNOWLEDGE"：侦听器执行期间或之后的惰性消息确认；在抛出异常的情况下可能重新交付。 "sessionTransacted" 设置为 "true"：监听器执行成功后的事务确认；在抛出异常的情况下保证重新投递。
我想知道的是，为什么这些消息来源说的不同？如果一切都是真的那么我怎么知道 how/when 我的消息会被确认？
您错过了抽象容器 javadocs 中的关键短语...
The exact behavior might vary according to the concrete listener container and JMS provider used.
Spring 中最常用的侦听器容器是 DefaultMessageListenerContainer， 表现出这种行为 - 它旨在与事务一起使用（要么本地或外部事务管理器），以便能够回滚已确认的消息。它的侦听器在接收方法之后被调用，因此已经应用了标准的 JMS 自动确认。线程上的任何 JmsTemplate 操作也可以使用相同的会话 - 因此可以成为事务的一部分。
另一方面，SimpleMessageListenerContainer 使用传统的 MessageListener 并表现出标准的 JMS 行为（在 receive() 之前从 Consumer 调用侦听器 returns; 因此异常将停止 ack).
我建议您阅读这些具体实现的 javadoc。从 SMLC...
This is the simplest form of a message listener container. It creates a fixed
number of JMS Sessions to invoke the listener, not allowing for dynamic
adaptation to runtime demands. Its main advantage is its low level of
complexity and the minimum requirements on the JMS provider: Not even the
ServerSessionPool facility is required.
See the AbstractMessageListenerContainer javadoc for details on acknowledge
modes and transaction options.
For a different style of MessageListener handling, through looped
MessageConsumer.receive() calls that also allow for transactional reception of
messages (registering them with XA transactions), see
DefaultMessageListenerContainer.
我将为抽象容器上的文档打开一个 JIRA 问题，因为我知道它可能具有误导性。