Consider upgrading reference to StackExchange.Redis

[analogrelay]

On the advice of the StackExchange.Redis maintainers, we have held off on upgrading our version of StackExchange.Redis. We should revisit this later in the 5.0 release.

This applies to SignalR, but also to the Caching Redis extension. We can address them both together (and likely we'll be driving both) so I'll label area-signalr for tracking.

[analogrelay]

Suggest revisiting in preview4 milestone.

[shirhatti]

Triage note: StackExchange.Redis asked us to hold out for a bit. WE'll revisit in the 5.0 timeframe

[tebeco]

this is a very very long shot but I'll try,
@NickCraver @mgravell

I saw the previous version of StackExchange.Redis you were testing was rolled back and since then 2.1.28 and 2.1.30 were released.
I'm curious if it's still on hold or should i try to proceed here :
#20040
#20042
StackExchange/StackExchange.Redis#1387

[BrennanConroy]

@NickCraver

We've added more diagnostics and better error messaging (to distinguish between the earlier cases) in the 2.1.23 release (currently on MyGet). We'll get that dogfooded on Stack Overflow this week. It also adds more detection for binding redirect failures (at the pipelines layer) to users are alerted to more failure cases due to that.

I'd say poke me in 1-2 weeks please - we'll have been in prod for a while and get more follow-ups from users testing it. I'd like positive reports on better issue resolution then advise a bump here for all users to benefit.

We're also going to get a hold of the Azure Redis team and sanity check some previous decisions and see if tweaking some defaults makes sense (e.g. we have a theory about Redis instances going to "sleep" we think may be affecting some users...).

Do you have any updates on the newer Redis bits?

[NickCraver]

We have a large PR in progress to help the Sentinel bits - the support could be better and we're working through the API now. That's the largest "pending" thing we have - relevant here because it switches the connection strategy to be based on the connection string from the upstream library which makes it more generally usable, e.g. with this reference too. I'll sync with @mgravell tomorrow and get a recommendation here.

[mgravell]

There's also the hypothetical "pool" stuff. Pretty huge in terms of impact, if I can land it.

…

On Sun, 10 May 2020, 11:57 Nick Craver, ***@***.***> wrote: We have a large PR in progress to help the Sentinel bits - the support could be better and we're working through the API now. That's the largest "pending" thing we have - relevant here because it switches the connection strategy to be based on the connection string from the upstream library which makes it more generally usable, e.g. with this reference too. I'll sync with @mgravell <https://github.com/mgravell> tomorrow and get a recommendation here. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#20076 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAEHMFHGG6TZPHEKXGCMFLRQ2CAXANCNFSM4LSCSZWA> .

[BrennanConroy]

Friendly ping, were the impactful changes resolved?

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[tebeco]

hello @mgravell @NickCraver
As it will probably not be part of .net5.0, what wrong could happen if we try to force the transitivity of StackExchange.Redis to 2.1.* to avoid it being resolved to 2.0.* ?
I suppose as it's just a minor, it should be ok.

Also, the question is not specific to signalr but generally speaking for all Microsoft.AspNetCore.* and also Microsoft.Extensions.Caching.StackExchangeRedis

@BrennanConroy
naïve question, can Msft libs have transitive received minor update during its lifetime ?
more like
can this update be done during aspnetcore 5.0 lifetime ?
and can this update be done for Microsoft.Extensions.Caching.StackExchangeRedis ?

Or will it be net6.0 ?

[BrennanConroy]

We generally don't update our 3rd party references unless there is a very good reason such as breaking changes. Consumers can manually reference higher versions of the transitive references if they want updates to the other package. And as long as there are no breaking changes it should work.