如何避免在Azure可靠函数中出现PopReceiptMismatch错误

huangapple go评论70阅读模式
英文:

How to avoid PopReceiptMismatch errors in Azure durable functions

问题

对于我的Azure函数应用程序,需要使用分发架构,其中包括(子)编排器和大量并行运行的活动。此外,所有这些活动都需要与Azure Blob存储帐户进行交互。在处理这种高度并行化时,经常会遇到运行时错误,如下所示:

[2023-02-07T14:11:36.859Z] 4c6a215f040141aaaa995f9cfbf1a234:10: 处理消息时发生错误 [TaskScheduled#46]: DurableTask.AzureStorage.Storage.DurableTaskStorageException: 指定的弹出票据与出队消息的弹出票据不匹配。
[2023-02-07T14:11:36.860Z] ---> Microsoft.WindowsAzure.Storage.StorageException: 指定的弹出票据与出队消息的弹出票据不匹配。
[2023-02-07T14:11:36.861Z] 在Microsoft.WindowsAzure.Storage.Core.Executor.Executor.ExecuteAsyncInternal[T](RESTCommand1 cmd, IRetryPolicy policy, OperationContext operationContext, CancellationToken token)中执行异步操作 [2023-02-07T14:11:36.874Z] 在DurableTask.AzureStorage.Storage.AzureStorageClient.WrapFunctionWithReturnType(Func3 storageRequest, OperationContext context, CancellationToken cancellationToken)中包装带有返回类型的功能
[2023-02-07T14:11:36.875Z] 在DurableTask.AzureStorage.TimeoutHandler.ExecuteWithTimeout[T](String operationName, String account, AzureStorageOrchestrationServiceSettings settings, Func3 operation, AzureStorageOrchestrationServiceStats stats, String clientRequestId)中执行带超时的操作 [2023-02-07T14:11:36.876Z] 在DurableTask.AzureStorage.Storage.AzureStorageClient.MakeStorageRequest[T](Func3 storageRequest, String accountName, String operationName, String clientRequestId, Boolean force)中进行存储请求
[2023-02-07T14:11:36.877Z] 请求信息
[2023-02-07T14:11:36.879Z] 请求ID: 7db00ba3-1e70-42fc-84f5-f6dfb9ec630a
[2023-02-07T14:11:36.880Z] 请求日期: 2023年2月7日 星期二 15:11:36 GMT
[2023-02-07T14:11:36.896Z] 状态消息: 指定的弹出票据与出队消息的弹出票据不匹配。
[2023-02-07T14:11:36.897Z] 错误代码: PopReceiptMismatch
[2023-02-07T14:11:36.898Z] 错误消息: 指定的弹出票据与出队消息的弹出票据不匹配。
请求ID: 7db00ba3-1e70-42fc-84f5-f6dfb9ec630a
时间: 2023-02-07T14:11:36.137Z
[2023-02-07T14:11:36.901Z] --- 内部异常堆栈跟踪的末尾 ---

这些错误既不触发try-catch断点,也不停止代码执行,但确实非常烦人,并导致编排器重新启动,从而导致数据损坏。有没有适当的修复方法?

英文:

For my Azure functions application, a fan-out architecture with (sub-)orchestrators and a lot of activities running in parallel is required. Additionally, all these activities have to interact with an Azure blob storage account. When dealing with this high degree of parallelization, I often run into runtime errors like these:

[2023-02-07T14:11:36.859Z] 4c6a215f040141aaaa995f9cfbf1a234:10: An error occurred while processing message [TaskScheduled#46]: DurableTask.AzureStorage.Storage.DurableTaskStorageException: The specified pop receipt did not match the pop receipt for a dequeued message.[2023-02-07T14:11:36.860Z]  ---> Microsoft.WindowsAzure.Storage.StorageException: The specified pop receipt did not match the pop receipt for a dequeued message.
[2023-02-07T14:11:36.861Z]    at Microsoft.WindowsAzure.Storage.Core.Executor.Executor.ExecuteAsyncInternal[T](RESTCommand`1 cmd, IRetryPolicy policy, OperationContext operationContext, CancellationToken token)[2023-02-07T14:11:36.874Z]    at DurableTask.AzureStorage.Storage.AzureStorageClient.WrapFunctionWithReturnType(Func`3 storageRequest, OperationContext context, CancellationToken cancellationToken) in /_/src/DurableTask.AzureStorage/Storage/AzureStorageClient.cs:line 156[2023-02-07T14:11:36.875Z]    at DurableTask.AzureStorage.TimeoutHandler.ExecuteWithTimeout[T](String operationName, String account, AzureStorageOrchestrationServiceSettings settings, Func`3 operation, AzureStorageOrchestrationServiceStats stats, String clientRequestId)[2023-02-07T14:11:36.876Z]    at DurableTask.AzureStorage.Storage.AzureStorageClient.MakeStorageRequest[T](Func`3 storageRequest, String accountName, String operationName, String clientRequestId, Boolean force)
[2023-02-07T14:11:36.877Z] Request Information
[2023-02-07T14:11:36.879Z] RequestID:7db00ba3-1e70-42fc-84f5-f6dfb9ec630a
[2023-02-07T14:11:36.880Z] RequestDate:Tue, 07 Feb 2023 15:11:36 GMT
[2023-02-07T14:11:36.896Z] StatusMessage:The specified pop receipt did not match the pop receipt for a dequeued message.
[2023-02-07T14:11:36.897Z] ErrorCode:PopReceiptMismatch
[2023-02-07T14:11:36.898Z] ErrorMessage:The specified pop receipt did not match the pop receipt for a dequeued message.
RequestId:7db00ba3-1e70-42fc-84f5-f6dfb9ec630a
Time:2023-02-07T14:11:36.137Z
[2023-02-07T14:11:36.901Z]    --- End of inner exception stack trace ---

These neither trigger try-catch breakpoints nor stop code execution, but are really annoying and cause the orchestrators to restart which leads to data corruption down the road. Is there a proper way of fixing this?

答案1

得分: 1

当在Visual Studio中创建函数项目时,local.settings.json文件中的AzureWebJobsStorage值默认设置为true。将Azure函数配置为使用真实的存储账户来执行协调器可以消除并发问题和错误的状态管理。只需将该值替换为您自己存储的连接字符串:

{
  ...
  "Values": {
    "AzureWebJobsStorage": "[您的连接字符串在此]",
    ...
  }
}
英文:

When function projects get created in Visual Studio, the AzureWebJobsStorage value in the local.settings.json file is set to true by default. Configuring Azure functions to use a real storage account for orchestrators can eliminate concurrency issues and faulty state management. Simply replace the value with the connection string of your own storage:

{
  ...
  "Values": {
    "AzureWebJobsStorage": "[YOUR CONNECTION STRING HERE]",
    ...
  }
}

huangapple
  • 本文由 发表于 2023年2月8日 18:12:32
  • 转载请务必保留本文链接:https://go.coder-hub.com/75384238.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定