是否可以在尝试接收消息之前确定消息是否被锁定

Question

我正在使用 peek-lock 来使用 Azure.Messaging.ServiceBus SDK 版本 7.16.1 接收消息。

我正在使用

ServiceBusAdministrationClient

类检查队列上的活动消息。活动消息计数不考虑锁，例如可能无法接收活动消息，因为它可能被锁定。

鉴于

ServiceBusReceiver.ReceiveMessageAsync

方法通过轮询队列来工作，直到可以接收消息或直到超过

maxWaitTime

参数的值，我宁愿不尝试接收消息，除非我知道它不是已锁定。

我曾尝试在调用

ServiceBusReceiver.PeekMessageAsync

之前先调用

ServiceBusReceiver.ReceiveMessageAsync

检查锁定，但是，这似乎并不可靠 - 有时我知道已锁定的消息的

LockedUntil

属性被设置为默认值和其他值有时它似乎反映了先前已过期的锁。我想知道这是否是服务总线或 SDK 中的一个错误，或者它在查看消息时是否根本不可靠。

Answer 1

没有受支持且可靠的方法来确定消息在尝试接收之前是否被锁定。此处计算的任何结果都将是时间点的，并且在计算完成时可能是错误的；唯一可靠的方法是尝试获取锁。

您是否考虑过使用

maxWaitTime

的标称值，该值略高于适应预期消息大小的网络传输所需的时间？这通常比多次调用更快、更准确。在需要建立连接/链接/身份验证的场景中，这些仍然受重试策略的

TryTimeout

控制，不需要在

maxWaitTime

中考虑。

一些注意事项：

• Service Bus SDK 不会计算或修改

  LockedUntil

  时间；任何价值都直接来自服务。

• 与问题无关，但某些人可能感兴趣 - 服务总线客户端不进行轮询。尝试接收消息是单个 AMQP 操作，其中客户端向服务发出信号，然后等待消息流入。客户端在

  maxWaitTime

  后放弃并取消。

• 如果您想就此提出服务功能建议，最好的选择是 Azure 反馈站点的 服务总线论坛。