Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/StackExchange/StackExchange.Redis/issues/871 below:

The "network stability" / 2.0

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".

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".

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.

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.

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.

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.

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 Discussion required: remove PreserveAsyncOrder #877

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.

kierenj, manigandham, expcat, NickCraver, amirjalali1 and 32 moreamirjalali1, graboszczak and salzersoftwareamirjalali1, MarcusWichelmann and salzersoftwarecrackalak, adamsitnik, expcat, alentor, graboszczak and 6 more

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4