jms - 使用和不使用 Spring JMS 的 AUTO_ACKNOWLEDGEMENT 模式之间的区别

Question

我试图了解确认模式在 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 Docs 说其他事情:
来自 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”:成功监听器执行后的事务确认；在抛出异常的情况下保证重新交付。

我想知道的是，为什么这些消息来源说不同的话？如果一切都是真的，那么我怎么知道我的消息将如何/何时被确认？

Answer 1

你错过了抽象容器 javadocs 中的关键短语......
The exact behavior might vary according to the concrete listener container and JMS provider used.Spring中最常用的监听器容器是 DefaultMessageListenerContainer其中 表现出这种行为 - 它旨在与事务(本地或外部事务管理器)一起使用，以便能够回滚已确认的消息。它的监听器被调用 后 接收方法，因此已经应用了标准的 JMS 自动确认。任意 JmsTemplate线程上的操作也可以使用相同的 session ——因此可以是事务的一部分。

另一方面，SimpleMessageListenerContainer使用传统 MessageListener并表现出标准的 JMS 行为(在 Consumer 返回之前从 receive() 调用监听器；因此异常将停止 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 问题，因为我可以看到它可能具有误导性。