Do not deduce ServerSelectionStrategy in case of connection failures #1444
Conversation
Merging from master
dceravigupta
changed the title
dceravigupta
changed the title
|
I'm trying to understand what we're attempting to fix here. You said you're getting this issue on the If you're unable to upgrade to 2.x - I understand, but at the same time: there will be no more 1.x builds and so even if we did a commit to that branch (which isn't what |
|
Going to close this out as a 1.2.6 issue and we have tons of changes since then with far more info available in the exception to help show the exact issue. |
|
@NickCraver since people are also facing this problem in 2.1.3, should we reconsider taking this fix or something you guys recommend? |
|
@dceravigupta If you have a repro, is it possible to check it against 2.1.30 as well? If it's possible to reproduce the error in the latest version, then it should be no brainer for the maintainers to fix the issue and/or accept the fix. Moreover, I think many people (including myself and my team that faces this issue as well) will benefit from the repro you have because we'll be able to play around and actually try to fix the issue ourselves. So if you can share the repro it'll be fantastic! |
3 participants
Second attempt to fix problem described in the following thread. I'm adding details here as well for completeness of this PR.
We are using 1.2.6 version of StackExchange.Redis with Azure Redis cache and occasionally we get bunch of "No connection is available to service this operation" and sometime it goes into a state where it doesn't ever recover from this issue and we are forces to reboot those VMs to fix the problem.
I'm able to repro the problem locally and noticed that whenever it happens, ConnectionMultiplexer -> ReconfigureAsyc function fails while PINGing Redis Server and as a result the clusterCount remain 0.
Now since we are not sure what type of Redis we are talking to, we default to ServerSelectionStrategy.ServerType i.e. ServerType.Standalone. Now even if endpoints recover, we are still stuck with ServerSelectionStrategy.ServerType as Standalone due to which all subsequent calls fails with "No connection is available to service this operation".
I'm able to repo the same problem in v2.1.3 as well.