小编典典

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

redis

我正在经历所谓的 超时执行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


阅读 706

收藏
2020-06-20

共1个答案

小编典典

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

2020-06-20