我正在经历所谓的 超时执行HGET company:product:settings,inst:1,队列:8,qu = 0,qs = 8,qc = 0,wr = 0/0,in = 79/1 超时异常。
奇怪的是,同一Redis实例和同一台机器上正在存储数据,但是它是引发此异常的特定应用程序。 更新: 实际上,同一应用程序在上面的一行中,从Redis接收数据。问题在于HGET。
HGET
此外,我已经将多路复用器配置的超时增加到6秒,没有任何运气。
另外,我检查了IDatabase实例是否IsConnected具有true价值。
IDatabase
IsConnected
true
如何解释这些错误消息以及整个超时背后的问题是什么?
我已经成功解决了某些代码段获取 数据库 (即) 时 更改的问题。 __multiplexer.GetDatabase()
multiplexer.GetDatabase()
尽管 Multiplexer 具有AppDomainStackExchange.Redis文档中所述的实例,但是许多控制组件的反转都IDatabase在自己的代码中创建了许多实例。也就是说,IDatabase实例不共享。
AppDomain
实际代码执行ListRightPopLeftPush,然后实例化控制组件的反转,该反转将在组件初始化期间读取哈希键。如果在执行所谓的之前实例化整个组件ListRightPopLeftPush,那么整个组件HashGet将不会抛出超时异常。
ListRightPopLeftPush
HashGet
看起来,即使ListRightPopLeftPush从其他IDatabase实例执行IDatabase时,在执行读取操作时,它也会在下一个实例中产生某种问题。
无论如何,我的 修复程序无法解决 问题。我刚刚添加了更详细的信息,以让我们找到问题所在及其解决方案。
无论如何,上述“修复”将无法修复对Redis的进一步读取访问。我在进一步的通话中遇到了相同的超时异常。现在in在异常消息中发现的参数说60/1。
in
60/1
基于聊天中的长时间讨论以及大量的挖掘,在某些晦涩的情况下,TPL似乎在执行类似的操作时.TrySetResult(通常:)劫持了专用的阅读器线程。如果您进行同步调用,这将导致即时死锁,因为如果忙于等待任务完成(它只能自己完成),则它可能无法处理任何套接字数据。实际上,我们确实有 专门的[ 代码_来防止这种情况的发生_ ,但是,似乎解决方法实际上 迫使 它在某些其他情况下发生。哪个…太可怕了。我会看到我能找到的。但基本上,问题是, 目前 ,在 一些有限的情况下,TaskCompletionSource.TrySetResult正在赋予TPL权力以运行同步延续。这包括Task.WhenAny。
.TrySetResult
TaskCompletionSource.TrySetResult
Task.WhenAny