如何解决max-delivery-attempts不适用于未确认的邮件
我注意到Artemins的行为异常。我不确定这是错误还是我不明白。
我使用Artemis Core API。我将autoCommitAcks
设置为false
。我注意到,如果在MessageHandler
中收到了消息,但是消息没有得到确认并且会话已回滚,那么Artemis不会认为此消息尚未传递,Artemis认为此消息根本没有发送给消费者。在这种情况下,参数 max-delivery-attempts 不起作用。邮件被无限次发送。方法org.apache.activemq.artemis.api.core.client.ClientMessage#getDeliveryCount
每次返回1。 Web控制台的已发送列中的邮件具有false
值。如果在会话回滚之前已确认消息,则最大传递尝试将正常工作。
消息确认的目的到底是什么?确认表示仅接收到消息,还是确认表示已成功接收和处理消息?也许我可以通过两种方式使用确认,但这仅取决于我的要求吗?
通过消息确认,我的意思是调用org.apache.activemq.artemis.api.core.client.ClientMessage#acknowledge
方法。
解决方法
您所看到的行为是预期的。
核心客户端实际上使用来自 local 缓冲区的消息,该缓冲区异步填充了来自代理的消息。此本地缓冲区中的消息数据量由客户端URL上设置的consumerWindowSize
控制。代理可以将数千条消息分发给位于这些本地缓冲区中的各种客户端,而消费者实际上从未以任何身份看到它们。这些消息被认为是已交付,其他客户无法使用,但它们被未认为是已交付。仅当消息被确认后,才被视为传递给客户端。
如果客户端正在自动提交确认,则确认消息将迅速将其从其各自的队列中删除。从队列中删除该消息后,就无法再传递该消息,因为该消息已不再存在于代理中。简而言之,如果您自动提交确认,就无法获得可配置的重新交付语义。
但是,如果客户端不是 自动提交确认,并且消费者关闭(由于任何原因)而没有提交确认或在其rollback()
上调用ClientSession
,则客户端确认的消息将根据配置的重新发送语义(包括max-delivery-attempts
)重新发送。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。