Transient connection failures on Azure Redis instance

[MatanShabtay]

Hi,

We've been using StackExchange.Redis version 1.2.6 NuGet to communicate with our Azure instance for the last year. As we suffered from a lot of transient connection failures, we recently decided to upgrade the StackExchange.Redis NuGet version to 2.0.601 as it promised to be provide more network stabillity.

However, we are now getting a new type of transient errors, some of the errors I've collected are:

1. StackExchange.Redis.RedisConnectionException: UnableToConnect
2. StackExchange.Redis.RedisConnectionException: Failed to write ---> StackExchange.Redis.RedisConnectionException: No connection is available to service this operation: SET
   3.StackExchange.Redis.RedisConnectionException: SocketFailure on redis.server.dns

Our connection string contains the following configuration:

1. abortConnect=false
2. ssl=true

Our Cloud Service communicates with 2 different Azure Redis instances (each one different purposes) and both of them have the same issues.
Both Redis servers are not heavily utilized.

Can someone advise how can we overcome this transient errors except adding retry logic ?
Does anyone else suffers from the same issues?

Thanks.

[mgravell]

I've seen a few mentions of similar; it is on my backlog to investigate

…

On Mon, 20 May 2019 at 07:29, MatanShabtay ***@***.***> wrote: Hi, We've been using StackExchange.Redis version 1.2.6 NuGet to communicate with our Azure instance for the last year. As we suffered from a lot of transient connection failures, we recently decided to upgrade the StackExchange.Redis NuGet version to 2.0.601 as it promised to be provide more network stabillity. However, we are now getting a new type of transient errors, some of the errors I've collected are: 1. StackExchange.Redis.RedisConnectionException: UnableToConnect 2. StackExchange.Redis.RedisConnectionException: Failed to write ---> StackExchange.Redis.RedisConnectionException: No connection is available to service this operation: SET 3.StackExchange.Redis.RedisConnectionException: SocketFailure on redis.server.dns Our connection string contains the following configuration: 1. abortConnect=false 2. ssl=true Our Cloud Service communicates with 2 different Azure Redis instances (each one different purposes) and both of them have the same issues. Both Redis servers are not heavily utilized. Can someone advise how can we overcome this transient errors except adding retry logic ? Does anyone else suffers from the same issues? Thanks. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1149?email_source=notifications&email_token=AAAEHMCKFUMF5DEXDRILWI3PWJANXA5CNFSM4HN63EFKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GUURYJQ>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAEHMD6OMD7LTDP76OOEB3PWJANXANCNFSM4HN63EFA> .

-- Regards, Marc

[mstavrev]

@MatanShabtay, we are also getting from time to time such intermittent disconnects. In most cases, these are caused by changes/maintenance on either Azure networking infrastructure or the VM(s)/Hypervisor machine servicing your particular Redis instance. Very often, when I detect such an error, if I user redis console and ask for "INFO SERVER", I see the uptime_in_seconds is a very small value, e.g. the Redis instance had been restarted, or moved to a new VM. When this happens any client connection would be dropped and the client reestablishes a new one to the new instance.

[NickCraver]

This won't be fixed for 1.2.6 (the issue is different and there will be no more 1.x releases). The 2.x flavor of similar issues is being tracked in #1120 with additional fixes in #1374. Closing this out just to collapse into those issues.

Without going through all those: in a cloud provider they failover and sever your connection. It happens. That's how they work. And there's nothing we can do about it...so the suggestion on retry logic for things that are safe to retry (e.g. incrementing an account balancer wouldn't be...because maybe it was a response that got dropped, and not a request) is the way to go. Only you can make that determination of what's safe in your app though.