Tho*_*sen 5 c# azure azureservicebus azure-servicebus-queues azure-webjobs
我有一个Azure WebJob函数,用于侦听Azure ServiceBus队列上的消息。通常,当我在代码中遇到异常时,根据Azure WebJobs SDK文档,该消息将被放弃:
如果功能成功完成,SDK会在PeekLock模式下接收一条消息,并在消息上调用Complete,如果功能失败,则调用Abandon。如果该函数的运行时间超过了PeekLock超时时间,则该锁定将自动更新。
根据Azure ServiceBus文档,这应该意味着该消息再次变得可用,并将被重试:
如果应用程序由于某种原因无法处理该消息,则可以对收到的消息调用AbandonAsync方法(而不是CompleteAsync)。此方法使Service Bus可以解锁消息并使其可以由同一使用者或另一个竞争使用者再次接收。其次,存在与锁定相关联的超时,并且如果应用程序未能在锁定超时到期之前处理消息(例如,如果应用程序崩溃),则服务总线将消息解锁并使其可以再次接收(基本上是)默认情况下执行AbandonAsync操作)。
上面描述的行为是通常发生的情况,但是我发现了此规则的例外。如果我的代码TaskCanceledException
专门抛出了该消息,则该消息不会被丢弃,而应该这样做:
public void ProcessQueueMessage([ServiceBusTrigger("queue")] BrokeredMessage message, TextWriter log)
{
throw new TaskCanceledException();
}
Run Code Online (Sandbox Code Playgroud)
通过Web作业运行此功能时,我看到错误消息打印成一天,但该消息被使用而没有重试,也没有进入死信队列。如果我将TaskCanceledException
上述内容替换为InvalidOperationException
,则该消息将被绑定并重试(应根据实际的ServiceBus队列进行了验证)。
我无法找到有关此行为的任何解释。目前,我将换成TaskCanceledException
另一个例外来解决此问题。
我正在遇到Azure WebJobs SDK中的错误吗?TaskCanceledException
在这方面是否特殊,或者其他类型的异常是否具有类似的行为?
我正在使用以下NuGet软件包:
如果执行不成功,函数应该放弃该消息。如果您说消息没有被放弃并重试,即使它应该被放弃和重试(假设MaxDeliveryCount
设置为大于 1 并且接收模式为PeekLock
),那么这可能是函数的问题,而不是 Azure 服务总线的问题。您可以通过运行控制台应用程序并执行相同的操作来验证这一点,检查消息是否已完成并从队列中删除或仍在队列中并可供使用。
另外,看起来您正在使用旧版本的 WebJobs(和 Azure 服务总线)。执行验证时,您需要使用旧版 Azure 服务总线客户端 ( WindowsAzure.ServiceBus ),而不是新客户端 ( Microsoft.Azure.ServiceBus )。