-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Is using ForceReconnect still necessary for using Azure Redis? #1996
Comments
The idea is that when everything is in place, the library should deal with those server maintenance events for you - we added them in discussion with the Azure redis team. As for ForceReconnect: honestly I don't know, but I can try to find out; maybe @philon-msft knows something? |
Hi @navidmatin we developed ForceReconnect as a backstop for rare cases where a StackExchange.Redis ConnectionMultiplexer instance got stuck in a state where its internal connection restoration was unable to reconnect. Those cases are becoming even more rare as we continue to track down issues that can interfere with reconnection inside SE.Redis. The Azure Cache for Redis team still recommends ForceReconnect for Redis client apps that are having problems with connection stability, or need an additional layer of protection to reinitialize stalled connections. But with the latest versions of SE.Redis, it's becoming less important. We recommend the same pattern for other client libraries too, but we don't currently have sample projects demonstrating it in other languages. The specific issue you mention about pub/sub connections not being restored should be fixed by #1947. In the upcoming release with that change, you should see all connections restored reliably without needing ForceReconnect or ServerMaintenanceEvents. |
Thank you both this information has been informative. |
@navidmatin FWIW a prelease is up on NuGet with the pub/sub fixes - if you're willing to give it a go we'd love any reports back! |
+1 to Nick's suggestion for trying the new 2.5.27-prerelease version to eliminate the issues you're seeing with pub/sub connections. |
@NickCraver I added the pre-release version to the app, the only comment I have so far is that I've noticed when the Redis server is unavailable and the flag
Other than that everything appears to be working as expected. |
@navidmatin ah great note - is this a case where you can't connect for a while on startup that succeeds later? |
@NickCraver yes that is correct. An easy way to reproduce this is to just use the local Redis instance and start the application and attempt to subscribe to a channel before starting the Redis service. |
@navidmatin Thanks for the info btw - I'm not sure how to best handle this. I consider the current to be a net win in that it will work and subscriptions are much improved on reliability vs. before, but indeed if it doesn't succeed right then, the command will fail. I feel this is correct but happy to be shown otherwise here. I'm thinking maybe some beefy documentation clarification on the method pointing this out with example scenarios? Thoughts? |
I think this sounds good. I'm going to close this. |
I had basically this same question, so asking here instead of another ticket. Is ForceReconnectAsync still recommended for Azure Cache for Redis using latest version of this client? It seems enhancements are being made on client and server, so wondering. My use case is MSAL distributed token cache using Redis on Azure. |
While reading Microsoft Best Practices around Azure Redis I came upon this https://docs.microsoft.com/en-us/azure/azure-cache-for-redis/cache-best-practices-connection#using-forcereconnect-with-stackexchangeredis which talks about using "ForceReconnect" approach which appears to be a very specific implementation of using StackExchange.Redis. However, I can't find anything on StackExchange.Redis that talks about this, and Microsoft explanation is very vague so I have the following questions:
I started looking into this while trying to troubleshoot an issue with our servers unsubscribing from Redis Pub/Sub channel without any exception after Microsoft patching our Azure Redis instances. I'm trying to find the best way to prevent this from happening in the future.
The text was updated successfully, but these errors were encountered: