最大传递-尝试不适用于未确认的消息。
我注意到了青蒿素的奇怪行为。我不确定这是个bug还是我不明白什么。我使用。我将autoCommitAcks设置为false。我注意到，如果在MessageHandler中接收到消息，但是消息未被确认，会话被回滚，那么Artemis并不认为此消息未被传递，Artemis认为此消息根本没有发送给使用者。在这种情况下，参数max-delivery-attempts不能工作。消息被重新传递了无数次。方法org.apache.activemq.artemis.api.core.client.ClientMessage#getDeliveryCount每次返回1。消息在重传的web控制台中的列中具有值。如果在会话回滚之前确认了消息，那么max-delivery-attempts就能正常工作。
信息确认的目的到底是什么？“确认”意味着只接收到该消息，还是“确认”意味着该消息已被成功接收和处理？也许我可以两种方式使用确认，它只取决于我的需求？
通过消息确认，我的意思是调用org.apache.activemq.artemis.api.core.client.ClientMessage#acknowledge方法。
回答 1
Stack Overflow用户
发布于 2020-10-30 18:45:28
你看到的行为是意料之中的。
核心客户端实际上使用来自本地缓冲区的消息，该缓冲区包含来自代理异步的消息。此本地缓冲区中的消息数据量由客户端URL上的consumerWindowSize设置控制。代理可能会发送数千条消息给不同的客户端，这些客户端位于这些本地缓冲区中，消费者从未真正以任何身份看到它们。这些消息被认为是在传递中，其他客户端不能使用，但它们不被认为是传递的。只有当消息被确认时，它才被认为是被传递给客户端的。
如果客户端是自动提交确认，那么确认消息将迅速将其从其各自的队列中删除。一旦消息从队列中删除，它就不能再被重新传递了，因为它不再存在于代理上。简而言之，如果您自动提交确认，就无法获得可配置的重发语义。
但是，如果客户端不是自动提交确认，并且使用者(由于任何原因)关闭，而不提交确认或在其rollback()上调用ClientSession，那么确认的消息将根据配置的重传语义(包括max-delivery-attempts)重新传递。
https://stackoverflow.com/questions/64604801
复制相似问题
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号