Azure webjob似乎不尊重MaxDequeueCount属性

我有一个Azure webjob，它有几个队列触发函数。位于的SDK文档将

MaxDequeueCount

属性定义为：

将队列消息发送到队列之前的最大重试次数 毒药队列（默认值为5）

但我没有看到这种行为。在我的网络工作中，我有：

JobHostConfiguration config = new JobHostConfiguration();
config.Queues.MaxDequeueCount = 1;
JobHost host = new JobHost(config);
host.RunAndBlock();

然后我得到了一个队列触发函数，其中我抛出了一个异常：

public void ProcessQueueMessage([QueueTrigger("azurewejobtestingqueue")] string item, TextWriter logger)
{
   if ( item == "exception" )
   {
      throw new Exception();
   }
}

查看webjobs仪表板，我看到SDK进行了5次尝试（如上所述，默认为5次）：

在第五次尝试后，消息被移动到中毒队列。我希望看到1次重试（或不重试？），而不是5次

更新：启用web应用的详细日志记录，并选择将这些日志保存到Azure blob容器。在azure作业主机存档容器中找到了一些与我的问题相关的日志。下面的示例显示了一个出列计数为96的项目：

{
  "Type": "FunctionCompleted",
  "EndTime": "2017-02-22T00:07:40.8133081+00:00",
  "Failure": {
    "ExceptionType": "Microsoft.Azure.WebJobs.Host.FunctionInvocationException",
    "ExceptionDetails": "Microsoft.Azure.WebJobs.Host.FunctionInvocationException: Exception while executing function: ItemProcessor.ProcessQueueMessage ---> MyApp.Exceptions.MySpecialAppExceptionType: Exception of type 'MyApp.Exceptions.MySpecialAppExceptionType' was thrown.
  },
  "ParameterLogs": {},
  "FunctionInstanceId": "1ffac7b0-1290-4343-8ee1-2af0d39ae2c9",
  "Function": {
    "Id": "MyApp.Processors.ItemProcessor.ProcessQueueMessage",
    "FullName": "MyApp.Processors.ItemProcessor.ProcessQueueMessage",
    "ShortName": "ItemProcessor.ProcessQueueMessage",
    "Parameters": [
      {
        "Type": "QueueTrigger",
        "AccountName": "MyStorageAccount",
        "QueueName": "stuff-processor",
        "Name": "sourceFeedItemQueueItem"
      },
      {
        "Type": "BindingData",
        "Name": "dequeueCount"
      },
      {
        "Type": "ParameterDescriptor",
        "Name": "logger"
      }
    ]
  },
  "Arguments": {
    "sourceFeedItemQueueItem": "{\"SourceFeedUpdateID\":437530,\"PodcastFeedID\":\"2d48D2sf2\"}",
    "dequeueCount": "96",
    "logger": null
  },
  "Reason": "AutomaticTrigger",
  "ReasonDetails": "New queue message detected on 'stuff-processor'.",
  "StartTime": "2017-02-22T00:07:40.6017341+00:00",
  "OutputBlob": {
    "ContainerName": "azure-webjobs-hosts",
    "BlobName": "output-logs/1ffd3c7b012c043438ed12af0d39ae2c9.txt"
  },
  "ParameterLogBlob": {
    "ContainerName": "azure-webjobs-hosts",
    "BlobName": "output-logs/1cf2c1b012sa0d3438ee12daf0d39ae2c9.params.txt"
  },
  "LogLevel": "Info",
  "HostInstanceId": "d1825bdb-d92a-4657-81a4-36253e01ea5e",
  "HostDisplayName": "ItemProcessor",
  "SharedQueueName": "azure-webjobs-host-490daea03c70316f8aa2509438afe8ef",
  "InstanceQueueName": "azure-webjobs-host-d18252sdbd92a4657d1a436253e01ea5e",
  "Heartbeat": {
    "SharedContainerName": "azure-webjobs-hosts",
    "SharedDirectoryName": "heartbeats/490baea03cfdfd0416f8aa25aqr438afe8ef",
    "InstanceBlobName": "zd1825bdbdsdgga465781a436q53e01ea5e",
    "ExpirationInSeconds": 45
  },
  "WebJobRunIdentifier": {
    "WebSiteName": "myappengine",
    "JobType": "Continuous",
    "JobName": "ItemProcessor",
    "RunId": ""
  }
}

不过，我要进一步查找的是日志，这些日志将向我显示特定队列项目的详细信息，其中处理成功（因此从队列中删除）或由于异常而失败，并被放置在有毒队列中。到目前为止，我还没有找到任何显示该细节的日志。上述输出中引用的日志文件不包含此类数据

更新2：查看我的毒药队列的状态，看起来可能是一支冒烟的枪，但我太密集了，无法将2和2放在一起。查看下面队列的屏幕截图，您可以多次看到ID为（左列）

431210

的消息。它多次出现的事实向我表明，原始队列中的消息失败不正确

---

我怀疑这是因为你没有实际运行你认为你在Azure中的二进制文件。这一次也让我大吃一惊

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

这是因为Kudu默认情况下会将所有WebJob文件复制到临时目录并执行它们。从：

WebJob被复制到%TEMP%\jobs{job]下的临时目录中 键入}{job name}{random name}，并将从此处运行此选项 防止锁定原始WebJob二进制文件，这可能会 导致重新部署WebJob时出现问题。例如，更新.exe文件 当前正在运行的

确保新发布的触发WebJob实际运行的唯一成功方法是执行以下操作：

登录Kudu控制台。是的。您将使用与登录Azure门户时相同的凭据

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

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

然后我跳到门户，浏览到托管WebJob的Web应用管理刀片，单击WebJobs菜单选项，确认旧WebJob不再存在

从Visual Studio发布我的新WebJob

---

这应该保证您正在运行发布的代码。希望这有帮助

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}");
            }
        }

日志信息请参考屏幕截图

我看到了同样的情况，消息超过了最大出列次数。我将在稍后发布更多的细节，但我也看到一个非常大的数字最终出现在毒药队列中。因此，我怀疑它会在5之后加入毒药队列，但尝试更多的结果会在毒药队列中大量出现（数百）。
如果您仍在寻找答案，我们尝试了列出的一些答案，但没有成功。事实证明，这是存储sdk（WindowsAzure.Storage）和Webjob sdk（Microsoft.Azure.WebJobs）的版本问题。为了修复它，我们不得不将我们的存储sdk版本降级到7.2.1（我们最近升级到了8.1.1）。根据下面的文章，工程师们现在已经意识到了这些问题，并有望很快将其修复：

正如Rob W所提到的，使用WindowsAzure.Storage>7.1.2时存在此问题。该问题显然已在中修复，但尚未发布

供款人已共享了一个关于。这似乎解决了问题（对我来说效果很好）

如果发生链接损坏，为了满足SO规则，以下是帖子和代码片段：

对于那些（像我一样）不能等待下一个版本获得
WebJobs SDK可与最新版本的Azure Storage配合使用，以及
根据@brettsam的解释，您只需编写一个自定义
CustomQueueProcessorFactory在中创建新的CloudQueueMessage
CopyMessageTopoIsQueueAsync

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

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

对于使用Azure WebJobs v3.x SDK的任何人：
在v3.x中，hosts.json不适用于WebJob

相反，版本3.x使用标准ASP.NET核心API，因此需要使用ConfigureWebJobs方法对其进行配置：

static async Task Main()
{
    var builder = new HostBuilder();
    builder.ConfigureWebJobs(b =>
    {
        b.AddAzureStorageCoreServices();
        b.AddAzureStorage(a => {
            a.BatchSize = 8;
            a.NewBatchThreshold = 4;
            a.MaxDequeueCount = 4;
            a.MaxPollingInterval = TimeSpan.FromSeconds(15);
        });
    });
    var host = builder.Build();
    using (host)
    {
        await host.RunAsync();
    }
}

文档：
您是否在Azure上运行
var config = new JobHostConfiguration();
config.Queues.QueueProcessorFactory = new CustomQueueProcessorFactory();

static async Task Main()
{
    var builder = new HostBuilder();
    builder.ConfigureWebJobs(b =>
    {
        b.AddAzureStorageCoreServices();
        b.AddAzureStorage(a => {
            a.BatchSize = 8;
            a.NewBatchThreshold = 4;
            a.MaxDequeueCount = 4;
            a.MaxPollingInterval = TimeSpan.FromSeconds(15);
        });
    });
    var host = builder.Build();
    using (host)
    {
        await host.RunAsync();
    }
}