The content from this article has been moved to a happier home on our official documentation site - please update your bookmarks.
-
-
Save JonCole/317fe03805d5802e31cfa37e646e419d to your computer and use it in GitHub Desktop.
-
Last I tested this (before StackExchange.Redis 2.0 was released), connection blips from the server being patched could result in all three of the exceptions you listed, so you need to expect any of these can happen. I don't know if/how that has changed since 2.0 was released.
-
Any exception thrown might indicate that the operation you tried to perform could have failed, but, unfortunately, it is very difficult to say for sure. I have a short section on when to retry inside of my best practices doc that may help clarify.
I have also updated the above doc to recommend that you use the reboot feature as a way to test how your application is affected by connection blips during failover.
Is there a metric and/or event that we can track in a dashboard to correlate spikes in RedisConnectionException with patching/failover timelines?
https://docs.microsoft.com/en-us/azure/azure-cache-for-redis/cache-how-to-monitor#available-metrics-and-reporting-intervals has an "errors" metric that can be used to see failover events. We are planning on surfacing some audit events for patching as well, but I can't say yet when that will be available.
Can you share a code sample of how this must be implemented? The text can be interpreted differently by different people.
For example,
Do we need to retry for
TimeoutException
,RedisConnectionException
orSocketException
even if abortConnect is set to false?There is a statement above:
StackExchange.Redis will retry connection attempts - it will not retry operations. It is up to the application to retry operations.
What does this mean? Retry the operations for what exceptions? (the above mentioned ones?) What if abortConnect is set to false and StackExchange.Redis will automatically reconnect? Do we still need to retry the operation?