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

Question

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

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

此外，我已经将多路复用器配置的超时增加到6秒，没有任何运气。

另外，我检查了IDatabase实例是否IsConnected具有true价值。

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

一些背景…

我已经成功解决了某些代码段获取 数据库 （即） 时 更改的问题。 __multiplexer.GetDatabase()

尽管 Multiplexer
具有AppDomainStackExchange.Redis文档中所述的实例，但是许多控制组件的反转都IDatabase在自己的代码中创建了许多实例。也就是说，IDatabase实例不共享。

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

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

无论如何，我的 修复程序无法解决 问题。我刚刚添加了更详细的信息，以让我们找到问题所在及其解决方案。

更新资料

无论如何，上述“修复”将无法修复对Redis的进一步读取访问。我在进一步的通话中遇到了相同的超时异常。现在in在异常消息中发现的参数说60/1。

Answer 1

基于聊天中的长时间讨论以及大量的挖掘，在某些晦涩的情况下，TPL似乎在执行类似的操作时.TrySetResult（通常：）劫持了专用的阅读器线程。如果您进行同步调用，这将导致即时死锁，因为如果忙于等待任务完成（它只能自己完成），则它可能无法处理任何套接字数据。实际上，我们确实有
专门的[ 代码_来防止这种情况的发生_ ，但是，似乎解决方法实际上 迫使
它在某些其他情况下发生。哪个…太可怕了。我会看到我能找到的。但基本上，问题是， 目前 ，在 一些有限的情况下，TaskCompletionSource.TrySetResult正在赋予TPL权力以运行同步延续。这包括Task.WhenAny。