Question

有时候，在大约10000个兔子背囊中，有1个我无法正确确认。

在我遇到message A失败的情况下，我也不例外。似乎一切顺利。当我进入下一个message B队列时，我得到了异常System.IO.EndOfStreamException: SharedQueue。堆栈跟踪表明异常是在RabbitMQ.Util.SharedQueue.EnsureIsOpen()中引发的，这是私有方法。

有问题-A message没有被确认！确认时我也没有例外，但仍然没有确认！两个应用程序获得相同消息的可能性很小。我有什么可以做的吗？

我已经尝试更改某些设置，例如：

AutomaticRecoveryEnabled = true;
RequestedHeartbeat = 60;
NetworkRecoveryInterval = TimeSpan.FromSeconds(10);

并在每次确认之前编写了一种测试连接的方法：

public bool HasFullConnection() {
    if (!HasServerConnection(Config.ConnectionConfig.HostAddress)) return false;
    if (!RabbitMQConnection.IsOpen) return false;
    if (!RabbitMQClient.IsOpen) return false;

    return true;
}

不幸的是-问题仍然存在。

Answer 1

因此，这里发生了几件事。首先，您可能已经发现，C＃客户端库不能很好地处理异常情况。其次，更重要的是，您的应用程序设计要求ack上具有100％的可靠性，而这不是必须的。

10,000的故障率为1（或0.01％）是相当不错的。如果您仅在0.01％的邮件上看到ack失败，我认为这是可以接受的失败级别。 RabbitMQ中的确认异步传递到代理，并且基于最初接收到消息的渠道和使用者。从收到消息到实际确认消息之间可能发生许多事情。因此，如果发生任何影响使用者，渠道，代理或连接的事件，则假定该消息已失败并重新发送。

这至少称为一次交货。替代方法是最多一次交货（替代方法不使用确认）。因此，假设您最多使用一次传递，则系统应设计为处理重新传递的消息。

确认消息失败时没有错误

1 个答案: