【问题标题】:Azure Blob Trigger Function and System.Threading.SleepAzure Blob 触发器函数和 System.Threading.Sleep
【发布时间】:2022-01-08 11:15:33
【问题描述】:

我们使用 Interfax 作为我们的传真提供商。 我们有一个 Azure Blob 存储帐户,以及一个由新上传触发的函数。 当我们上传 blob 时,该函数被调用,这部分工作正常。 事实上,大多数调用都能正常工作,但有些调用会丢失。

发送传真后,我们有一个循环来检查状态。 在每次状态检查后,我们调用 System.Threading.Sleep(120000)。

其中大约 15% 似乎卡住了。 我们跟踪了该事件,似乎它没有从 sleep 调用中返回。

一些信息提到不要在 .NET azure 函数中使用 System.Threading.Sleep。

是否有人对我们如何解决此问题有任何其他建议, 甚至对可能发生的事情有任何其他见解?

目前我们在 2 分钟的睡眠中尝试了 30 次,这意味着某些 Azure Blob 触发的函数可以运行一个多小时。也许许多并行调用会导致问题?

【问题讨论】:

  • 2min sleep inside 函数不是好习惯。如果您需要等待一段时间才能知道传真发送的状态,您应该考虑保持功能等待以外的其他方式。参考 Azure 函数timeout limits
  • 请参阅此 MS document 了解如何解决如此长时间运行的逻辑
  • 另外,请分享有关您发送传真的更多详细信息 - 您是否调用 REST 服务或任何其他方式,该提供商是否提供任何回调(webhook),以便您可以避免 循环等待并检查发送状态。
  • 我们曾经使用 twillio,它有一个 webhook,但这个提供者没有。我们正在考虑从服务中删除状态检查并使其作为 Windows 服务运行。您非常喜欢持久计时器链接,我认为在此期间我们可能会这样做以使其再次运行,然后在服务上工作。
  • 是的,很高兴为您提供帮助,您可以存储传真请求句柄并使用另一个计时器触发功能或服务检查其状态。我也将其发布为答案。

标签: .net azure blob sleep fax


【解决方案1】:

Azure 函数的执行时间应该尽可能短,并且在超时限制内。超时limits 因托管函数应用程序的层/计划而异。

对于您的方案,最好使用建议的方法之一来处理此类长时间运行的逻辑。女士document。一种方法是让durable function 检查状态,甚至是timer 触发器,每X 分钟/秒检查一次传真请求的状态。 如果传真提供商提供更适合使用的回调(webhook)。

【讨论】:

    猜你喜欢
    • 2021-03-26
    • 1970-01-01
    • 2018-08-29
    • 1970-01-01
    • 2021-10-08
    • 1970-01-01
    • 1970-01-01
    • 2023-03-22
    • 2022-10-25
    相关资源
    最近更新 更多