在 StackExchange.Redis 中等待异步命令和 Task.WhenAny 后的超时异常

Question

我正在经历所谓的超时执行 HGET company:product:settings, inst: 1, queue: 8, qu=0, qs=8, qc=0, wr=0/0, in =79/1 超时异常。

这很奇怪，因为同一台机器上的同一个 Redis 实例正在存储数据，但它是一个特定的应用程序引发了这个异常。 更新：其实同一个应用，上面一行从Redis接收数据。问题在于HGET。

另外，我将多路复用器配置的超时时间增加到 6 秒，但没有运气。

此外，我检查了IDatabase 实例具有IsConnected 和true 值。

如何解释这些错误消息以及整个超时背后的问题是什么？

一些背景...

我已成功解决了更改当某些代码部分获得数据库（即multiplexer.GetDatabase()）的问题。

虽然 multiplexer 如 StackExchange.Redis 文档中所述，每个 AppDomain 都有一个实例，但许多控制反转组件正在自己的代码中创建许多 IDatabase 实例。也就是说，IDatabase 实例未共享。

实际代码执行ListRightPopLeftPush，然后实例化控制组件的反转，该组件在组件实例化期间读取哈希键。如果在做所谓的ListRightPopLeftPush之前实例化整个组件，那么整个HashGet就不会抛出超时异常。

似乎即使从其他IDatabase 实例执行ListRightPopLeftPush，在执行读取操作时也会在下一个IDatabase 实例中产生某种问题。

无论如何，我的 fix 没有回答这个问题。我刚刚添加了更详细的信息，以便我们找到问题所在和自己的解决方案。

更新

无论如何，上述“修复”不会修复对 Redis 的进一步读取访问。我在进一步的调用中遇到了相同的超时异常。现在in 异常消息中的参数显示60/1。

Answer 1

基于long discussion in chat 和大量挖掘，看起来在一些模糊的场景中，当我们执行.TrySetResult 之类的事情时，TPL 正在劫持专用的阅读器线程（我们经常这样做）。如果您进行同步调用，这会导致即时死锁，因为如果它正忙于等待任务完成（这只会自行完成），它就不可能处理任何套接字数据。我们确实有code in place specifically to prevent this，但看起来解决方法实际上强制它在某些其他情况下发生。这……太可怕了。我会看看我能找到什么。但基本上，问题在于当前，在一些有限的场景中，TaskCompletionSource.TrySetResult 正在为 TPL 提供运行同步延续的权力。这包括Task.WhenAny。