代码之家  ›  专栏  ›  技术社区  ›  m1nkeh

Azure EventHub和函数LeaseLostException

  •  1
  • m1nkeh  · 技术社区  · 6 年前

    我们在我们的消费计划功能应用程序上看到异常奇怪的行为,请注意我们反复看到的以下异常:

    • Microsoft.Azure.EventHubs.RecieverDisconnectedException (将创建新的epoch为“2”的接收器,因此epoch为“1”的当前接收器将断开连接。)
    • System.Net.WebException (引发了“Microsoft.ServiceBus.Messaging.LeaseLosTestException”类型的异常。)

    每当我们强调功能时,我们都会遇到这些异常,即在几分钟内从0到50000个事件,但它们与我们的功能应用程序匹配的云角色挂钩。。这会让我相信这是主机错误。。

    阅读各种文档,即( https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-features ),我 认为 我理解EventHub接收器是如何工作的(但老实说,我是在两行之间读取的,因为这很不清楚),因为我的一个接收器依赖于一个消费者组来管理从EventHub分区(我使用的是32)读取的消息批。

    我的假设是,在负载情况下,有太多的功能实例需要单个使用者组来“处理”,它只是重复地切换分区的租约。。。但是,在我的测试场景中,除了在事件集线器之间中继消息之外,我从函数中删除了所有逻辑,即使事件集线器上只有4个分区,错误仍然存在

    为了查看是否在以后的版本中得到了解决,我在FunctionsV2中模拟了完全相同的功能,并得到了我所假设的.net核心等价物。。

    1. Microsoft.Azure.EventHubs.RecieverDisconnectedException (将创建新的epoch为“2”的接收器,因此epoch为“1”的当前接收器将断开连接。)
    2. Microsoft.WindowsAzure.Storage.StorageException (指定的租约ID与blob的租约ID不匹配。)
    3. System.ArgumentOutOfRangeException (忽略偏移量为1184072/序号为1038的过期检查点,因为..)

    所以,能不能请个人

    • 解释到底是什么 事实上 在掩护下进行
    • 帮助我抑制这些,如果它们不是真正的“真实”错误,它们只是管理事情的主机。。。

    这些异常真的很烦人,因为它使得实际看到真正的未处理异常变得相当棘手。

    1 回复  |  直到 6 年前
        1
  •  5
  •   Ling Toh    6 年前

    这些错误都是由于函数应用程序(宿主进程)中的函数的动态伸缩而导致的,您可以忽略它们。

    可以理解的是,它们出现在您的日志中这一事实令人担忧,我们已经开始了一些工作来抑制一些错误(参见 https://github.com/Azure/azure-webjobs-sdk/issues/1760 ). 这是随版本发布的 v1.0.11913 你应该把它们看作是警告。仁慈的 file an issue 如果它们仍然显示为错误。


    关于您为什么会看到这些异常的其他背景

    让我们从一些关于EventHub缩放如何工作的初步内容开始,如本文所述: https://stackoverflow.com/a/42911842/6465830

    一。Microsoft.ServiceBus.Messaging.LeaseLostException

    每次扩展操作成功时,EventHub都会在 (1..N) 一组 EventProcessorHosts 它成功地在分区上获得了租约,其中 N个 是EventHub的分区数。例如,如果你从 功能 当我们扩展到 功能1 EventHub决定在两个函数之间均匀分布消息,然后 功能 将失去5个分区的租约。这种行为解释了 Exception of type 'Microsoft.ServiceBus.Messaging.LeaseLostException' was thrown 你看到的。

    2。Microsoft.Azure.EventHubs.ReceiverDisconnectedException

    此外,Azure的功能也扩展到 >N个 实例,因此将有一组 N+1…米 ,其中 无法在任何分区上获取租约的已扩展实例总数。这样做的副作用是总是会有一个EPH准备好迅速抢到一个丢失的租约,以保持管道运行。这就解释了 New receiver with higher epoch of '2' is created hence current receiver with epoch '1' is getting disconnected. 你看到的。同样,只有在执行函数时才会对您收费,因此这里存在一些过度供应的事实不会影响您的计费。