React to changes in StackExchange.Redis 2.0
DamianEdwards opened this issue · 35 comments
Details at StackExchange/StackExchange.Redis#871
I think we'd look at upgrading our dependency to 2.0 and knocking out the soon to be obsolete StackExchange.Redis.StrongName package in the 3.0 timeframe.
SignalR too?
Yep
Oh yeah
cc @mgravell
StackExchange.Redis 2.0 is out, Given the perf improvements in StackExchange.Redis 2.0 It is tempting to backport this to 2.2-preview or 2.2 release?
I just installed https://www.nuget.org/packages/Microsoft.Extensions.Caching.Redis.Core and saw how old the redis package was. It is also owned by https://www.nuget.org/profiles/LonghronShen which looks weird and phishy.
I would love to see this updated in the next 2.2 preview or release.
That is definitely not our package.
@BrennanConroy Would you kindly deal with that package and provide the real package location. Is it https://www.nuget.org/packages/Microsoft.Extensions.Caching.Redis/2.2.0-preview1-35029
PS: I found it from this msdn article https://blogs.msdn.microsoft.com/luisdem/2016/09/06/azure-redis-cache-on-asp-net-core/
Thanks for the quick response!
the nuget package name squatting is a problem.
The package name must have changed because it is referenced in this blog post also: https://dotnetthoughts.net/configuring-redis-for-aspnet-core-session-store/
@DamianEdwards what about this repo https://github.com/aspnet/DataProtection is it needed to open a different issue there?
I see that this is scheduled for a 3.0 release, but is there any chance it could happen sooner?
There's a memory leak issue with the StackExchange.Redis.StrongName version 1.2 that appears to be solved in StackExchange.Redis version 2.0.
@DamianEdwards @davidfowl what are the chances for 2.2 here?
I'm broke because one dependency using 2.0 of the redis client and the Extensions.Caching.Redis is using v1...
Severity Code Description Project File Line Suppression State
Error CS0433 The type 'ConnectionMultiplexer' exists in both 'StackExchange.Redis.StrongName, Version=1.2.6.0, Culture=neutral, PublicKeyToken=c219ff1ca8c2ce46' and 'StackExchange.Redis,
Please backport to 2.2....
@niemyjski backport? We haven't shipped 2.2 yet. I'm not sure it's reasonable to make this kind of breaking change in 2.2. We'll discuss it.
To bring the changes planned for 3.0 to 2.2 (upgrading redis). The redis client 2.0 changes have been stable for us but broke lots of things with the package name changing.
also time out issues get solved in stackexchange.redis 2.0.
it would be nice to see redis 2 on microsoft sooner
@davidfowl I fully understand it's unreasonable to make this kind of change but we're about to yank Redis from our application due to ongoing issues. We've had StackExchange.Redis 1.x make SignalR unusable on three separate occasions due to thread starvation from connectivity issues. Obviously that means we will have to go down to one node and can no longer do no downtime deployments but I don't think I can keep our CEO at bay. Redis is literally a four letter word in his world at this point....
I really don't want to live in a single node world until sometime in 2019 if at all possible.
I don't think it's OK to make such a breaking change in 2.2, but we can certainly create a new package that has the newer dependency and do that in 2.2. And then in 3.0 we'd stop building the old package.
Would that work?
Being able to remove StackExchange.Redis 1.x by any means necessary in 2.2 would be better than waiting for 3.0
I'm officially pulling Redis sessions from a Core app today because of major timeout issues. If possible, I'm cheering for a 2.2 on this one as well.
Thanks @Eilon I sincerely appreciate you getting this started
Similar issues here. I don't really care what we have to do to update to Redis 2.x, as long as there is a way. We have a serious memory leak originating from this issue that was fixed in redis 2:
+1
Thanks to all the devs that are working on this (and for all the work you do on all projects).
Can we please though get a definitive, authoritative answer as to when this issue may be resolved?
Though I am sure it is not related, ever since patching in CVE-2018-8409, our apps are getting increasing Redis connection issues causing our SessionCache to fail. I don't care if the app cache fails, since then it would fall over, but I have no fall-over for SessionCache failing.
If we don't know when this will be resolved, I will have to pull out Redis Sessions all together and come up with another application and session caching solution.
Again, thanks for all your time and efforts!
We have a serious memory leak originating from this issue that was fixed in redis 2:
Same issue here.
What @Eilon suggests in #410 (comment) would work fine:
but we can certainly create a new package that has the newer dependency and do that in 2.2. And then in 3.0 we'd stop building the old package.
StackExchange released a new Redis library StackExchange.Redis V2.0.x
We'll be creating a new package: Microsoft.Extensions.Caching.StackExchangeRedis which uses that.
StackExchange released a new Redis library StackExchange.Redis V2.0.x
We'll be creating a new package:
Microsoft.Extensions.Caching.StackExchangeRediswhich uses that.
Planned for 2.2.0?
Yes
Amazing, looking forward for the 2.2.0 release!
Fixed in #424
We will pick up the preview3 release and put it through the paces.
@buvinghausen Let us know if you see any issues! Thanks!