Stackexchange.redis: The "network stability" / 2.0 / "pipelines" rollup issue

[mgravell]

I'm creating this as a placeholder to close (combine) a number of tracked issues that can basically be summarized as:

I get connection stability issues.

(this could also mean unusual timeouts)

This is the number one support query we get, and I could fully understand it if you feel frustrated that we haven't magically fixed it. Well: good news: we haven't been ignoring you. We have been actively working on a major set of changes that overhaul the entire network layer. The deliverables of this work are, in order:

• network connection stability
  
  
  
  • especially on TLS (cloud), non-Windows systems and .NET Core
  
  
• better protection from thread-pool starvation
• lower allocations generally
• better handling of "backlog" network buffers
• cleaner code

We plan is to release this as the next "major", 2.0.

Current status: "alpha-ish", with a public alpha drop in the next week or so. We intend to dogfood in production at Stack Overflow before we release anything "beta", and finally "stable".

---

Q: What does this mean for my current bug?

The reality is, with a network overhaul imminent, we're not going to do anything significant "else" to the network code in the 1.* branch, without a very good reason. So: we're going to close all the existing 1.* network stability issues as "see this".

Q: So you don't care about my 1.* bug?

On the contrary. We care so much that we've invested significant time and effort doing this overhaul precisely to fix the issue affecting you.

Other significant changes in 2.0

Packaging

We are getting rid of the StackExchange.Redis / StackExchange.Redis.StrongName duality; it is an unnecessary confusion and overhead. Right now, our guess is to:

• strong name StackExchange.Redis
• make StackExchange.Redis.StrongName take a package dependency on StackExchange.Redis
• make StackExchange.Redis.StrongName an empty shell which just type-forwards to StackExchange.Redis

Target platforms

We currently target .NETStandard 1.5, .NETFramework 4.5 and .NETFramework 4.6. With 2.0 we are planning to streamline the library to target .NETStandard 2.0 only. As a consumer, you can use this from any of:

• .NET Standard 2.0 or above
• .NET Framework 4.6.1 or above
• .NET Core 2.0 or above

If you're stuck on .NET Framework below 4.6.1 - I feel your pain, but it is becoming impossible to support that, sorry.

Technical details

Basically, we're rewriting the network core to utilize Pipelines. Pipelines do many of the same things that we already had code for in StackExchange.Redis, but it does it better, cleaner, and in ways that should work cross-platform. We're also making extensive use of the new Span<T> / Memory<T> features (which are closely related to Pipelines) to reduce allocations, and just a general spruce, tidy, nip and tuck. And just the general benefit of finding a block of time to stare at redis, more redis, and nothing but redis.

Q: Can I start playing with it?

If you really must, I won't stop you - it is the pipelines branch. Naming is hard. Please don't use it in production at this point. If you see any bugs, feel free to log them, but please mention that you're using 2.0 in the title.

Q: 2.0 - so... an API breaking change?

The only API breaking change here so far is the change of strong name; that by itself is a breaking change, assuming you're using the non-strong-named StackExchange.Redis package.

More subtle changes:

• there is a new overload of SetPop for popping multiple items; because of the implicit conversion between the literal zero and any enum, it is a little unclear to the reader whether db.SetPop(key, 0) pops zero items, or pops 1 item using the default flags. We consider this to be an unlikely usage in both real existing code (passing the enum as a literal zero) and new code (intending to always pop zero items); only the literal zero (0) is affected
• we are strongly considering removing support for PreserveAsyncOrder; we think this is a significant cause of performance problems; the most common scenario for this flag is for pub/sub, so a new API similar to a queue is being considered, based on Channel<T>; see #877

Q: Will there be any more 1.* builds?

Yes, but probably not very many. My hope is to get the "streams" PR merged (amazing work there, thanks @ttingen) as a 1.* nuget package, at a minimum.

---

Feedback welcome on any of these plans.

[NickCraver]

Note: potential breaking change, if we want, in response to #724.

//cc @mgravell

[NickCraver]

Note for later: I've anecdotally seen CanNotOpenNonsenseConnection_DNS seem to hang every other running test while it's pending. We may have a bottleneck in there somewhere. Other tests were trivial and should have been instant, but they hang like they're blocked behind the DNS completion.

[effyteva]

If I understand correctly, the current 1.2.6 release doesn't include the network stability fixes.
Perhaps it would make more sense to release 1.2.7 with all the checked-in updates?
Thanks!

[mgravell]

@effyteva the checked in updates in this branch are way too big to be included in a 1.; there *is a possibility of releasing another (final?) 1.2.* with the "streams" API changes, but: it won't include the stability changes - that's basically a complete ground-up overhaul of everything between the network layer and the public API

[effyteva]

Thanks @mgravell, waiting patiently for the 2.0 release.

[anneomcl]

Is there a vague estimate of the full 2.0 release date? Just curious.

[mgravell]

We're trying to track down a lingering issue that is slightly confusing
command order in a very rare corner case. Basically, "when we've done that"

• that's pretty much the one remaining factor.

On Thu, 9 Aug 2018, 01:58 Anne, [e-mail] wrote:

Is there a vague estimate of the full 2.0 release? Just curious.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/StackExchange/StackExchange.Redis/issues/871#issuecomment-411602892,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDsIgmFWNRF66Ba5wRhGNTeHAvY4GWks5uO4k_gaJpZM4U78j8
.

[NickCraver]

For everyone following along here: 2.0.495 (RTM) is now available on NuGet. We've been running the bits in production Stack Overflow for about a week now and have seen far fewer stability issues (the main goal of v2).

Release notes are up at: https://stackexchange.github.io/StackExchange.Redis/ReleaseNotes
NuGet up at: https://www.nuget.org/packages/StackExchange.Redis

Closing this out to cleanup, but please file an issue if you run into one!

[zhangruiskyline]

Hi, I have upgrade my stackexchange.redis from 1.2.6 to 2.0 and suddenly I have redis exception as

"Cache Get ExceptionNo connection is available to service this operation: GET key; UnableToConnect on xxxx.redis.cache.windows.net:6380/Interactive, Flushed, last: ECHO, origin: ResetNonConnected, outstanding: 9, last-read: 11s ago, last-write: 9s ago, unanswered-write: 9s ago, keep-alive: 60s, state: ConnectedEstablishing, mgr: 10 of 10 available, last-heartbeat: never, global: 9s ago, v: 2.0.505.18761; IOCP: (Busy=1,Free=999,Min=6,Max=1000), WORKER: (Busy=6,Free=8185,Min=6,Max=8191), Local-CPU: n/a"

I have not changed any code, is there some API change from 1.2.6 to 2.0?

[mgravell]

No, there's no change there - and we've tested against azure cache (it
worked just fine). It looks like the problem is during the initial connect.
Does this error happen continually / repeatably?

On Mon, 24 Sep 2018, 22:24 Rui Zhang, [e-mail] wrote:

Hi, I have upgrade my stackexchange.redis from 1.2.6 to 2.0 and suddenly I
have redis exception as

"Cache Get ExceptionNo connection is available to service this operation:
GET key; UnableToConnect on xxxx.redis.cache.windows.net:6380/Interactive,
Flushed, last: ECHO, origin: ResetNonConnected, outstanding: 9, last-read:
11s ago, last-write: 9s ago, unanswered-write: 9s ago, keep-alive: 60s,
state: ConnectedEstablishing, mgr: 10 of 10 available, last-heartbeat:
never, global: 9s ago, v: 2.0.505.18761; IOCP:
(Busy=1,Free=999,Min=6,Max=1000), WORKER:
(Busy=6,Free=8185,Min=6,Max=8191), Local-CPU: n/a"

I have not changed any code, is there some API change from 1.2.6 to 2.0?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/StackExchange/StackExchange.Redis/issues/871#issuecomment-424130205,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDsP1XIUkMfQfDwaOO7cYO8S5hSTpKks5ueU14gaJpZM4U78j8
.

[zhangruiskyline]

yes, it happened consistently. Actually I am not able to get successful connection at all. the same code worked for 1.2.6 though. I just installed 2.0 version, is there some connection multiplexer changes? or missing lib I need to use for 2.0 instead of 1.2.6?

[mgravell]

No, this should just work. Can you indicate exactly which runtime
you're running on here, so I can try locally against our azure servers?

On Tue, 25 Sep 2018, 07:58 Rui Zhang, [e-mail] wrote:

yes, it happened consistently. Actually I am not able to get successful
connection at all. the same code worked for 1.2.6 though. I just installed
2.0 version, is there some connection multiplexer changes? or missing lib I
need to use for 2.0 instead of 1.2.6?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/StackExchange/StackExchange.Redis/issues/871#issuecomment-424228872,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDsNZ9UmBsLST80u7BM6z05yYWnvQ6ks5uedQGgaJpZM4U78j8
.

[zhangruiskyline]

I am using a Azure function to access redis. at starting point just use connection multiplexer to establish connection. is there additional step to get connection from connection pool? let me check the code tomorrow and I can paste it here.

[mgravell]

Ah, I've tested on regular azure clients, but I haven't tested "azure
functions". I wonder if that is the fun wrinkle here. I'll have to set
something up

On Tue, 25 Sep 2018, 08:12 Rui Zhang, [e-mail] wrote:

I am using a Azure function to access redis. at starting point just use
connection multiplexer to establish connection. is there additional step to
get connection from connection pool? let me check the code tomorrow and I
can paste it here.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/StackExchange/StackExchange.Redis/issues/871#issuecomment-424232070,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDsBXq1hfTHFtPUxhHpvyp79mJtM_vks5ueddjgaJpZM4U78j8
.

[zhangruiskyline]

but 1.2.6 just works fine. so maybe you can check what could be difference? I mainly want to change to 2.0 because I saw 2.0 manage its dedicated thread pool, so we should have less chance for redis timeout when worker thread > min thread. (https://github.com/StackExchange/StackExchange.Redis/blob/master/docs/Timeouts.md). but dose that mean 2.0 create redis connection in other thread pool than main thread?

[mgravell]

The entirety of the network part of the codebase has been completely
rewritten, for context. But: it should work on azure. My first guess here
is "assembly binding redirect problems" related to the hosting environment.
I'll try to set something up.

On Tue, 25 Sep 2018, 08:19 Rui Zhang, [e-mail] wrote:

but 1.2.6 just works fine. so maybe you can check what could be
difference? I mainly want to change to 2.0 because I saw 2.0 manage its
dedicated thread pool, so we should have less chance for redis timeout when
worker thread > min thread. (
https://github.com/StackExchange/StackExchange.Redis/blob/master/docs/Timeouts.md).
but dose that mean 2.0 create redis connection in other thread pool than
main thread?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/StackExchange/StackExchange.Redis/issues/871#issuecomment-424233897,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDsElBhhRGAjpYkHuuMV_oIQ1gmLiqks5uedkMgaJpZM4U78j8
.

[mgravell]

Ooh, idea. The Connect method has an optional log parameter. If you pass in
a StringWriter to that, then access the .ToString() in the exception, it
may tell us a lot more.

On Tue, 25 Sep 2018, 08:23 Marc Gravell, [e-mail] wrote:

The entirety of the network part of the codebase has been completely
rewritten, for context. But: it should work on azure. My first guess here
is "assembly binding redirect problems" related to the hosting environment.
I'll try to set something up.

On Tue, 25 Sep 2018, 08:19 Rui Zhang, [e-mail] wrote:

but 1.2.6 just works fine. so maybe you can check what could be
difference? I mainly want to change to 2.0 because I saw 2.0 manage its
dedicated thread pool, so we should have less chance for redis timeout when
worker thread > min thread. (
https://github.com/StackExchange/StackExchange.Redis/blob/master/docs/Timeouts.md).
but dose that mean 2.0 create redis connection in other thread pool than
main thread?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/StackExchange/StackExchange.Redis/issues/871#issuecomment-424233897,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDsElBhhRGAjpYkHuuMV_oIQ1gmLiqks5uedkMgaJpZM4U78j8
.

[danmml]

To add to this as I was also having a similar issue with Azure Redis caches and upgrading to 2.0.505, adding in the following before the ConnectionMultiplexer.Connect call made it more clear what the binding redirect issue was:

AppDomain.CurrentDomain.FirstChanceException += (sender, eventArgs) =>
{
Console.WriteLine(eventArgs.Exception.ToString());
};

@mgravell Is it possible to surface these binding errors up to the initial Connect call? This would make it more clear to others trying to upgrade to > 2.0 what the underlying issue is. Even adding in the Console writer as suggested above still writes out a generic error about being "Unable to connect" to the server.

[mgravell]

Yes, we know it is causing problems - especially in the azure functions
case. I'm going to be adding tweaks tomorrow to surface this more clearly.

On Tue, 25 Sep 2018, 18:04 danmml, [e-mail] wrote:

To add to this as I was also having a similar issue with Azure Redis
caches and upgrading to 2.0.505, adding in the following before the
ConnectionMultiplexer.Connect call made it more clear what the binding
redirect issue was:

AppDomain.CurrentDomain.FirstChanceException += (sender, eventArgs) =>
{
Console.WriteLine(eventArgs.Exception.ToString());
};

@mgravell https://github.com/mgravell Is it possible to surface these
binding errors up to the initial Connect call? This would make it more
clear to others trying to upgrade to > 2.0 what the underlying issue is.
Even adding in the Console writer as suggested above still writes out a
generic error about being "Unable to connect" to the server.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/StackExchange/StackExchange.Redis/issues/871#issuecomment-424421881,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDsJjM8YpM1SrpIOtKBRds5nDAznSCks5uemIwgaJpZM4U78j8
.

[zhangruiskyline]

Great, Looking forward the fix. BTW, in 2.0, can we get rid of too many worker thread causing timeout problem as indicated in https://stackexchange.github.io/StackExchange.Redis/Timeouts?

[mgravell]

Yes, the threading model for callbacks is significantly different in 2.0

My first stab at a fix for the assembly bindings problem is now available,
btw.

On Tue, 25 Sep 2018, 22:16 Rui Zhang, [e-mail] wrote:

Great, Looking forward the fix. BTW, in 2.0, can we get rid of too many
worker thread causing timeout problem as indicated in
https://stackexchange.github.io/StackExchange.Redis/Timeouts?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/StackExchange/StackExchange.Redis/issues/871#issuecomment-424504549,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDsNqgJZuNmMieU3dFgRCgV5VPIJh3ks5uep1JgaJpZM4U78j8
.

[zhangruiskyline]

Sounds good, which version will have your fix?

[mgravell]

https://www.nuget.org/packages/StackExchange.Redis/2.0.510 - sorry, I should have updated the release notes - will do in the morning

[mgravell]

@danmml we're pushing out another version soon which should fix this assembly binding problem

[visharm]

@mgravell : Can we use 2.0.510? Is it a stable version without any known issues.

[NickCraver]

@visharm We're using 2.0.513 in production at Stack Overflow right now. We will strive to never knowingly push a build with issues to NuGet as stable :)

[mgravell]

I'd rather you used 513. It took a couple of builds to really nail the
assembly binding problem (510 wasn't any worse, but wasn't really any
better either, it turns out).

On Wed, 3 Oct 2018, 18:32 visharm, [e-mail] wrote:

@mgravell https://github.com/mgravell : Can we use 2.0.510? Is it a
stable version without any known issues.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/StackExchange/StackExchange.Redis/issues/871#issuecomment-426726718,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDsLbXX2pizlIimz2uFILfPmVh_o6Gks5uhPS5gaJpZM4U78j8
.

[visharm]

Okay, do you plan to fix it in the coming versions soon? if so when?

[mgravell]

Which "it" are you talking about? Can you be specific? If you mean the
assembly binding problem: 513

On Wed, 3 Oct 2018, 19:37 visharm, [e-mail] wrote:

Okay, do you plan to fix it in the coming versions soon? if so when?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/StackExchange/StackExchange.Redis/issues/871#issuecomment-426749327,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDsO1Iatd8RSpQr9gLFjfdQmUeeAevks5uhQPggaJpZM4U78j8
.

[visharm]

yes the assembly binding issue

[mgravell]

Then you should be good with 513, which is available on nuget.

On Wed, 3 Oct 2018, 19:56 visharm, [e-mail] wrote:

yes the assembly binding issue

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/StackExchange/StackExchange.Redis/issues/871#issuecomment-426756721,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDsPSHVU2UNq869zMhlYH9biU7Rs0sks5uhQhcgaJpZM4U78j8
.

[visharm]

Oh so its already fixed in 513? But I thought you mentioned even 513 has some assembly binding issues.
Your reply above:
_I'd rather you used 513. It took a couple of builds to really nail the
assembly binding problem_

[mgravell]

Exactly. I'd rather you used 513 because that has all the relevant fixes.

On Wed, 3 Oct 2018, 19:58 visharm, [e-mail] wrote:

Oh so its already fixed in 513? But I thought you mentioned even 513 has
some assembly binding issues.
Your reply above:

I'd rather you used 513. It took a couple of builds to really nail the
assembly binding problem

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/StackExchange/StackExchange.Redis/issues/871#issuecomment-426757236,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDsD1b3VEVeHVdN5NnMmPrxtQuoh_sks5uhQjKgaJpZM4U78j8
.

[visharm]

Okay thanks

[zhangruiskyline]

Just want to know whether stackexchange 2.0 has supported the reconnect function mentioned in

https://gist.github.com/JonCole/925630df72be1351b21440625ff2671f#reconnecting-with-lazyt-pattern

[visharm]

Hi All,

I noticed the latest version of StackExchange.Redis is 2.0.513.
Do we have a corresponding update to the strong name Nuget also?
StackExchange.Redis.StrongName.

[karaziox]

As per the release notes for 2.0, at https://stackexchange.github.io/StackExchange.Redis/ReleaseNotes#20495, the StackExchange.Redis.StrongName is deprecated.
The "StackExchange.Redis" package is now strongly named, you should be using that one.

[bridev]

We are using pacakge .571 with Azure Premium P1 and we are getting intermittent failures around 1 or 2 times a day where Redis stops responding and accepting connections for a few seconds with the only error: StackExchange.Redis.RedisConnectionException: SocketFailure

[dorpo]

We are using the 2.0.571 as well, and updated from 1.0.481.
Our client is a classic cloud service running in Azure with a 2-shard Redis Cluster.

We are getting these RedisConnectionException errors at a very high volumne, and these can only be resolved by restarting it.

Did you find any recurrence of this still happening in 2.x?

[patricksuo]

@dorpo

There are several lock/perf issues fixed in 2.0.571+ .
see https://stackexchange.github.io/StackExchange.Redis/ReleaseNotes

[dorpo]

Thanks, but this is the same old RedisConnectionException issue solved by restarting the client, which was supposedly resolved according to the author of this thread in Redis 2.X.

[mgravell]

If you're testing on 571, there is no way to make that statement.

On Thu, 11 Apr 2019, 12:51 dorpo, [e-mail] wrote:

Thanks, but this is the same old RedisConnectionException issue solved by
restarting the client, which was supposedly resolved according to the
author of this thread in Redis 2.X.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/StackExchange/StackExchange.Redis/issues/871#issuecomment-482082872,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDsL7p1nhsvdw3cgj8VPLcee0StuI0ks5vfyGygaJpZM4U78j8
.

[swapnashinde]

@mgravell

I am still getting below errors after updating it to 2.0.601. Could you please help.

Exception=StackExchange.Redis.RedisTimeoutException: Timeout performing GET (10000ms), next: PING, inst: 0, qu: 0, qs: 3, aw: False, rs: ReadAsync, ws: Idle, in: 0, in-pipe: 0, out-pipe: 0, serverEndpoint: Unspecified/:6379, mgr: 10 of 10 available, clientName: , IOCP: (Busy=0,Free=1000,Min=2,Max=1000), WORKER: (Busy=1,Free=2046,Min=2,Max=2047), v: 2.0.601.3402 (Please take a look at this article for some common client-side issues that can cause timeouts: https://stackexchange.github.io/StackExchange.Redis/Timeouts)
at StackExchange.Redis.ConnectionMultiplexer.ExecuteSyncImplT
at StackExchange.Redis.RedisDatabase.StringGet(RedisKey key, CommandFlags flags)

[jermeo]

Hello, same issue for me after upgrading to 2.0.601

The threads pools are far from saturated and the slowlog command show me only 0.1s for max execution time.

StackExchange.Redis.RedisTimeoutException: Timeout performing GET (5000ms), next: DEL 70243c1851f573aa99ae1499952b1a88a488e352, inst: 0, qu: 0, qs: 10, aw: False, rs: ReadAsync, ws: Idle, in: 0, in-pipe: 0, out-pipe: 712, serverEndpoint: Unspecified/REDIS-CLUSTER01:6379, mgr: 10 of 10 available, clientName: BDSSTT1 - PFG, IOCP: (Busy=17,Free=983,Min=400,Max=1000), WORKER: (Busy=78,Free=32689,Min=400,Max=32767), v: 2.0.601.3402

[chen1005]

Hi, I am seeing the same issue happened occasionally in 2.0.600.

Timeout performing SET (5000ms), inst: 0, qu: 0, qs: 1, aw: False, rs: ReadAsync, ws: Idle, in: 0, in-pipe: 0, out-pipe: 0, serverEndpoint: Unspecified/devredis:6379, mgr: 10 of 10 available, clientName: WEBAPPDEV3, IOCP: (Busy=0,Free=1000,Min=2,Max=1000), WORKER: (Busy=1,Free=32766,Min=2,Max=32767), v: 2.0.600.65315 (Please take a look at this article for some common client-side issues that can cause timeouts: https://stackexchange.github.io/StackExchange.Redis/Timeouts) at StackExchange.Redis.ConnectionMultiplexer.ExecuteSyncImplT

Not sure what's going on here.

[Sweiii]

Hi, i am seeing this problem also in my Azure instance

System.Exception: StackExchange.Redis.RedisTimeoutException: Timeout performing SCAN (5000ms), inst: 0, qs: 11, in: 0, serverEndpoint: Unspecified/coin-stream00-prod-cache.redis.cache.windows.net:6380, mgr: 10 of 10 available, clientName: CO0281, IOCP: (Busy=1,Free=999,Min=2,Max=1000), WORKER: (Busy=0,Free=8191,Min=2,Max=8191), v: 2.0.519.65453

[sd-charris]

I am seeing a similar issue on 2.0.601:

"Timeout performing GET (5000ms), next: GET REDACTED_KEY, inst: 1, qu: 0, qs: 124, aw: False, rs: ReadAsync, ws: Idle, in: 0, in-pipe: 0, out-pipe: 64, serverEndpoint: Unspecified/aws.elasticache.server.com:6379, mgr: 10 of 10 available, clientName: WEBSERVER1, IOCP: (Busy=0,Free=200,Min=50,Max=200), WORKER: (Busy=12,Free=788,Min=50,Max=800), v: 2.0.601.3402 (Please take a look at this article for some common client-side issues that can cause timeouts: https://stackexchange.github.io/StackExchange.Redis/Timeouts)"

stumped by this..

[humayun-ahmed]

I am facing same problem too... Timeout performing GET (1000ms) ...inst: 0, qu: 0, qs: 1, aw: False, rs: ReadAsync, ws: Idle, in: 0, in-pipe: 378134, out-pipe: 0, serverEndpoint: 172.26.102.216:6379, mgr: 10 of 10 available, clientName: NLC1DEOL121, PerfCounterHelperkeyHashSlot: 3805, IOCP: (Busy=0,Free=1000,Min=8,Max=1000), WORKER: (Busy=1,Free=2046,Min=8,Max=2047), v: 2.0.601
Stack trace

[mhdeyad]

Hi ,
I am facing the next problem :

after execute the line :
_db.StringSet....
I check the remote cache through the console to see if the key that passed above have been written in the cache,
but I didn't find it, even through when I write a key through the console it work fine.
Any Idea?

[ellenhutchings]

I know StrongName is deprecated, but is there an "empty" version to deal with dependencies that haven't updated to use the 2.0+ package for redirects?

[KamranShahid]

Can someone help me in https://github.com/StackExchange/StackExchange.Redis/issues/1248
Same .net core 3.0 application working on windows but throwing timeout error on ubuntu 18 machine

[timregs]

We have seen many of these connection issues happen from time to time in our application.

Is it recommended to retry the operation after a failure, or has anybody tried that with success?