即使使用 AutoLockRenew 也会向订阅者发送重复消息

Question

我在使用 azure sdk for python 收到来自 azure 服务总线主题订阅的消息后，正在使用 AutoLockRenew 类注册方法。

即使您在 python 中使用 AutoLockRenew.register() 方法自动为您更新锁 - 如果消息锁过期，renewable.renew_lock() 抛出异常，它会静默失败！

仍在执行业务逻辑的父线程继续执行（直到它调用message.complete()，实际上它会知道这一点）但同时，相同的消息出现在队列中，第二个实例将其用于处理！这意味着同一条消息现在正在被 2 个不同的接收者同时处理！

推荐的解决方法是什么？

代码如下所示 -

auto_renewer = AutoLockRenew()
with sub_client.get_receiver() as receiver:
    for message in receiver:
        auto_renewer.register(message)
        ....

Answer 1

（作为介绍，我是 python ServiceBus SDK 的开发人员之一。本来可以将此作为评论，但显然我在这里没有足够的声誉。）

一些想法：

1. 在 0.50.2 及之前版本中存在一个已知错误，如果消息处理时间超过 10 分钟，服务将终止关联的链接并且消息无法解决。 （事实上​​，正如您所描述的那样，它会被另一个接收器接收。）只需更新到 0.50.3（本周早些时候发布）就可以解决这个问题，因为您似乎正确地使用了自动更新，它已得到支持以保留相关链接活着。
2. 自动更新失败有点安静，因为它在一个单独的线程中执行它的工作，但它确实通过inner_exception 属性报告了这一点，当您尝试complete() 时抛出异常。如果您想尽快观察到这一点，可以查看消息中的auto_renew_error 字段。如果您看到的内容是由于上述第 1 点或其他原因，我很想知道该值被设置为什么，以便更好地进行三角测量。
3. 如果上述内容没有帮助，在这种情况下，查看更深入的日志记录输出会非常有用。这可以通过首先为“azure”和“uamqp”名称设置记录器（以查看堆栈中两个 python 组件的日志）并在创建 ServiceBusClient 时设置 debug=True（以查看来自底层 C 消息传递的日志）来启用lib，假设您使用的是 0.50.3 或更早版本，则该属性的名称已随版本 7.0.0b1 更改）。

关于未来的说明，如果您想与我们联系，请随时利用 github.com/Azure/azure-sdk-for-python 提出问题，因为这些问题非常重要我们。