azure-service-fabric - 什么会导致 ITransaction.CommitAsync 调用花费很长时间(24 小时)？

Question

我们在使用 ITransaction.CommitAsync 时遇到了一些奇怪的行为。有时，对 CommitAsync 的调用需要 24 小时才能完成。

在我们的场景中，我们每 5 分钟从硬件设备读取一次仪表数据，并将检查点存储在可靠的字典中。因此，每隔 5 分钟左右，就会运行以下代码:

var profileCheckpoints = await StateManager.GetOrAddAsync<IReliableDictionary<string, DateTime>>(StateNameProfileCheckpoints);

using (var tx = StateManager.CreateTransaction())
{
    // Dictionary key is a device guid + device register id,
    // e.g.: 13cdaad8-9b8b-4fba-b336-e72e06c047ab-1.0.99.1.0.255
    var key = GetCheckpointKey(context);

    // checkpoint is a DateTime
    await profileCheckpoints.SetAsync(tx, key, checkpoint);

    // this call will sometimes take 24h to complete
    await tx.CommitAsync();
}

我们有多个后台任务在有状态服务中运行。每个后台任务与单个硬件设备通信并运行上述代码。所有任务都使用相同的可靠字典，但只更新特定于设备的 key 。

一些任务运行得非常好，并且 CommitAsync 调用快速返回。对于其他任务，CommitAsync 调用可能会突然需要 24 小时才能完成。没有抛出异常，代码照常继续。一旦发生这种情况，除非我们重新启动服务，否则此任务的所有其他 CommitAsync 调用也将需要 24 小时才能完成。

集群和所有应用程序在门户中报告为健康。但是，当我查看不同节点上的事件查看器时，我看到记录了以下警告(大约每 5 秒一次):

dropping message <some guid>, Actor = Transport, Action = ‘’, fault = FABRIC_E_CONNECTION_CLOSED_BY_REMOTE_END

知道这可能是什么原因吗？

Answer 1

GetCheckpointKey 是否与设备通信？可能是这占用了一个线程并阻塞了，这意味着线程池正在耗尽。

可能是在抓着稻草，但 GetCheckpointKey 上没有 await 让我有点怀疑。