【问题标题】:Azure webjob - QueueTrigger stops triggeringAzure webjob - QueueTrigger 停止触发
【发布时间】:2015-11-23 04:13:22
【问题描述】:

我正在使用推荐的设置运行一个 azure webjobs SDK 控制台应用程序(连续):

public static void ProcessQueueMessage([QueueTrigger("logqueue")] string logMessage, TextWriter logger)

我正在运行的 azure 队列中有大约 6000 条消息,我正在本地运行 Web 作业,作为控制台应用程序。

我遇到的问题是在处理零到 30 条消息后随机停止处理。控制台保持打开状态,但不再显示控制台消息。

例如,它可能只处理 2 条消息:

Executing: 'Functions.ProcessQueueMessage' - Reason: 'New queue message detected on 'QueueName'.'
Executed: 'Functions.ProcessQueueMessage' (Succeeded)
Executing: 'Functions.ProcessQueueMessage' - Reason: 'New queue message detected on 'QueueName'.'
Executed: 'Functions.ProcessQueueMessage' (Succeeded)

然后,什么都没有。我的互联网连接似乎没有任何问题,我无法将问题追溯到任何特定消息。

还有其他人对此 SDK 有疑问吗?

更新:

我通过删除 nuget 包然后重新运行 install-package Microsoft.Axure.Webjobs 来确保我使用了所有依赖项的正确版本。我现在使用的 webjobs 版本 1.1.0 已经引入了 azure storage 的 4.3 版本。

按照 Matthew 的建议,我已经下载了 azure webjobs 的源代码,以确定进程冻结的位置。一旦发生冻结,我暂停执行并检查正在运行的线程,我认为这是Microsoft.Azure.WebJobs.Host.CompositeTraceWriter 中的罪魁祸首

    protected virtual void InvokeTextWriter(TraceEvent traceEvent)
    {
        if (_innerTextWriter != null)
        {
            string message = traceEvent.Message;
            if (!string.IsNullOrEmpty(message) &&
                 message.EndsWith("\r\n", StringComparison.OrdinalIgnoreCase))
            {
                // remove any terminating return+line feed, since we're
                // calling WriteLine below
                message = message.Substring(0, message.Length - 2);
            }

            _innerTextWriter.WriteLine(message);
            if (traceEvent.Exception != null)
            {
                _innerTextWriter.WriteLine(traceEvent.Exception.ToDetails());
            }
        }
    }

它冻结的行是第 66 行:_innerTextWriter.WriteLine(message);

_innerTextWriterSystem.IO.TextWriter.SyncTextWriter 的一个实例

这个类或它的使用方式是否可能存在一些死锁问题?

一些注意事项:

  • 我在调试器中运行,所以在这种情况下,我相信文本编写器正在内部转发到控制台
  • 我通过config.Queues.BatchSize = 1; 将批量大小设置为 1,不确定这是否重要

我目前正在另一台计算机上设置环境,以便我可以查看它是否可以在这台机器以外的其他地方重现(表面书)。

更新

问题是我不明白新的 Windows 10 命令提示符是如何工作的。每当您单击命令窗口时,它都会进入“选择”模式,会完全暂停进程的执行。

基本上:https://superuser.com/questions/419717/windows-command-prompt-freezing-randomly?newreg=ece53f5584254346be68f85d1fd2f18d

你可以知道它处于这种状态,因为它会在窗口标题前加上“选择”一词:

您必须按回车键或再次单击才能再次启动。

所以,最后两个 cmets:

1) 对于命令窗口来说,这是多么令人难以置信的令人困惑和不直观的行为!

2) 我希望一些管理员会同情我删除此问题给自己和家人带来的耻辱。

要摆脱这种奇怪的行为,您可以禁用快速编辑模式:

【问题讨论】:

    标签: azure azure-webjobs azure-webjobssdk


    【解决方案1】:

    奇怪。当它处于这种卡住状态时,您可以尝试将新的队列消息添加到队列中并查看是否触发?您确定您的功能没有在内部挂起吗?您使用的是什么版本的 SDK?您也可以尝试升级到我们上周刚刚发布的 v1.1.0。如果队列中真的有一堆消息等待处理,我想不出有什么会导致这种情况。 SDK 中的队列侦听器应该会继续运行,并行读取批量消息并将它们分派给您的函数。您是否更改了任何 JobHostConfiguration.Queues 配置旋钮?您还没有强制更新 Azure SDK 的版本是否高于 WebJobs SDK 支持的版本?

    如果您无法解决这个问题,另一种选择可能是克隆 SDK,在本地构建并调试它。 repo is here。主队列处理循环is here

    【讨论】:

    • 感谢 Mathew 的想法 - 我将进一步调查并在明天回复。您关于 azure SDK 与 webjobs SDK 版本控制的笔记听起来很有希望,因为当我拉下代码时,我确实与一些 nuget 包引用作斗争。我确实尝试了 webjobs 包版本 1.0.1,然后是 1.1.0,结果相似,但没有考虑其他依赖项。
    • v1.1.0 需要 4.3 版的 Azure 存储 SDK。我知道其他试图强制它使用更高版本的人遇到了问题。建议确保您使用的是正确的版本。
    • 对我之前的评论的误报 :( 我认为我将幸运连胜误解为正在解决的问题。
    猜你喜欢
    • 2016-05-11
    • 1970-01-01
    • 1970-01-01
    • 2014-12-12
    • 2016-09-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-03-03
    相关资源
    最近更新 更多