Azure webjob似乎不尊重MaxDequeueCount属性

5 回答

• 0

  正如Rob W所述，使用WindowsAzure.Storage> 7.1.2时存在此问题 . 这个问题显然已在_2524666中修复，但尚未将其发布 .

  贡献者asifferman在issue #985上共享了code snippet in a comment post . 这似乎解决了这个问题（它对我很有用） .

  如果链接腐烂，并满足SO规则，这里的帖子和代码片段：

  对于那些不能等待下一个版本的人来说，让WebJobs SDK与最新版本的Azure存储一起工作，并根据@brettsam的解释，你可以简单地编写一个自定义的CustomQueueProcessorFactory来创建一个新的CloudQueueMessage . CopyMessageToPoisonQueueAsync .

  namespace ConsoleApplication1
  {
      using Microsoft.Azure.WebJobs.Host.Queues;
      using Microsoft.WindowsAzure.Storage.Queue;
      using System.Threading;
      using System.Threading.Tasks;
  
      public class CustomQueueProcessorFactory : IQueueProcessorFactory
      {
          public QueueProcessor Create(QueueProcessorFactoryContext context)
          {
              return new CustomQueueProcessor(context);
          }
  
          private class CustomQueueProcessor : QueueProcessor
          {
              public CustomQueueProcessor(QueueProcessorFactoryContext context)
                  : base(context)
              {
              }
  
              protected override Task CopyMessageToPoisonQueueAsync(CloudQueueMessage message, CloudQueue poisonQueue, CancellationToken cancellationToken)
              {
                  var newMessage = new CloudQueueMessage(message.Id, message.PopReceipt);
                  newMessage.SetMessageContent(message.AsBytes);
  
                  return base.CopyMessageToPoisonQueueAsync(newMessage, poisonQueue, cancellationToken);
              }
          }
      }
  }
  

  然后在您的Main中，您只需在作业主机配置中设置自定义队列处理器工厂：

  var config = new JobHostConfiguration();
  config.Queues.QueueProcessorFactory = new CustomQueueProcessorFactory();
  

  我可以使用WindowsAzure.Storage 8.1.1和Microsoft.Azure.WebJobs 2.0.0 . 希望有所帮助！

  回复于 2024-04-29T10:12:24+08:00
• 6

  如果您仍在寻求答案，我们会尝试列出一些未成功的答案 . 事实证明，这是Storage sdk（WindowsAzure.Storage）和Webjob sdk（Microsoft.Azure.WebJobs）的版本问题 . 为了解决这个问题，我们最终不得不将我们的Storage sdk版本降级到7.2.1（我们最近升级到8.1.1） . 根据下面的文章，工程师现在已经意识到了这些问题，并希望很快就能解决这个问题：

  https://github.com/Azure/azure-webjobs-sdk/issues/1045

  回复于 2024-04-29T10:12:24+08:00
• 1

  如果我配置它，MaxDequeueCount属性可以正常工作 .

  所以它不适合你，这很奇怪 . 当我设置 config.Queues.MaxDequeueCount = 2; 然后我得到预期的结果请参考截图 .

  

  我们也可以使用 dequeueCount 来控制重试次数 . 以下是没有尝试的演示代码 .

  public void ProcessQueueMessage([QueueTrigger("queue")] string item, int dequeueCount, TextWriter logger)
          {
              if (dequeueCount == 1)
              {
                  if (item == "exception")
                  {
                      throw new Exception();
                  }
                  logger.WriteLine($"NewMsge: {item}");
                  Console.WriteLine($"NewMsge: {item}");
              }
          }
  

  日志信息请参考屏幕截图

  

  回复于 2024-04-29T10:12:24+08:00
• 0

  我怀疑这是因为你实际上并没有运行你认为你在Azure中的二进制文件 . 这个也把我扔了一个循环 .

  当您在Azure上运行触发的WebJobs时，发布新版本的WebJob不会导致旧的触发WebJob立即卸载并启动新的WebJob . 如果您查看WebJob日志，我怀疑您在重新发布时不会看到重新启动 .

  这是因为Kudu默认将所有WebJob文件复制到临时目录并执行它们 . 来自Kudu WebJob docs：

  WebJob被复制到％TEMP％\ jobs {作业类型} {作业名称} {随机名称}下的临时目录，并将从那里运行此选项可防止原始WebJob二进制文件被锁定，这可能导致重新部署WebJob的问题 . 例如，更新当前正在运行的.exe文件 .

  我确保新发布的触发WebJob实际运行的唯一成功就是做到了以下：

  • 登录Kudu控制台 . 这是https://yourappname.scm.azurewebsites.net . 您将使用登录Azure门户时所执行的相同凭据 .

  • 登录后，单击顶部的Process Explorer菜单选项 . 找到当前正在运行的WebJob进程并将其终止 .

  • FTP到您的Web应用程序 . 浏览到包含WebJob代码的目录，然后将其删除 . 它应该在/ app_data / jobs / triggered / [你的webjob名称]下 .

  • 然后我跳到门户网站，浏览到托管WebJob的Web App管理刀片，单击WebJobs菜单选项，并确认旧的WebJob不再存在 .

  • 从Visual Studio发布我的新WebJob .

  这应该保证您正在运行您发布的代码 . 希望这可以帮助 .

  回复于 2024-04-29T10:12:24+08:00
• 6

  我看到同样的事情，消息超过了最大出列计数 . 我会稍微发布一些细节，但我也看到了毒药队列中最后一个非常大的数字 . 所以我怀疑它是在5之后添加到毒物队列，但是尝试更多，最终在毒药队列中有很多（数百） .

  回复于 2024-04-29T10:12:24+08:00