-
-
Notifications
You must be signed in to change notification settings - Fork 456
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RetryHelper causing deadlock #300
Comments
No I think you are right, that To work around for now, could you try to set the retry trimeout to 0. This should always cause the Task.Delay to run synchronous. Or, set the retry count to zero, but that could cause a lot of unexpected exceptions because the client tends to throw timeouts randomly in some situations. |
Yes, we're currently on classic ASP.NET (in hopefully a not to distant future on ASP.NET Core though) but I guess it could happen in ASP.NET Core as well, but maybe it's not as likely somehow? I thought about those workarounds you suggested also, for avoiding the Task.Delay Wait to deadlock. I guess that having a few more retries than we have currently (to account for retries being more frequent) and lowering the timeout to 0 could at least do something for the better. Is it a tedious process to release a 1.2.1 hotfix or similar with just a fix for this? Can I help out with something in that case? |
Hi,
We had issues with a web site of ours that freezes from time to time. Looking at the process dumps, there's thousands of threads (initiated by web requests) waiting for a lock in the Eval method in RedisCacheHandle.cs, which is on this line as far as I can see:
CacheManager/src/CacheManager.StackExchange.Redis/RedisCacheHandle.cs
Line 977 in 4385c06
It seems as the reason for that is that one single thread is stuck in RetryHelper.cs, waiting forever for a Task.Delay on this line, that I guess was called because there was some temporary Redis server issue:
CacheManager/src/CacheManager.StackExchange.Redis/RetryHelper.cs
Line 43 in 3f3ad35
Doing .Wait() on a awaitable could AFAIK cause deadlocks when in ASP.NET request context because the synchronization context cannot be restored when the continuation is run: https://blog.stephencleary.com/2012/07/dont-block-on-async-code.html
I guess a workaround would be to add ConfigureAwait to avoid deadlock even though it's sort of a hack:
Task.Delay(timeOut).ConfigureAwait(false).GetAwaiter().GetResult();
Or just use
Thread.Sleep(timeOut)
in this case, or am I missing something?The text was updated successfully, but these errors were encountered: