Obsolete concurrency limiter middleware.

[mitchdenny]

Addresses #47532

[ghost]

@mitchdenny, this change will be considered for inclusion in the blog post for the release it'll ship in. Nice work!

Please ensure that the original comment in this thread contains a clear explanation of what the change does, why it's important (what problem does it solve?), and, if relevant, include things like code samples and/or performance numbers.

This content may not be exactly what goes into the blog post, but it will help the team putting together the announcement.

Thanks!

[mitchdenny]

Adding blog candidate tag for this so we can let folks know that we are obsoleting this middleware.

[mgravell]

see also src/Middleware/ConcurrencyLimiter/perf/Microbenchmarks/QueueEmptyOverhead.cs which is tripping CI failure

[ghost]

Thanks for identifying a breaking change.

, after you commit this PR please take the following actions, as part of the breaking changes announcement process:
\n- [ ] Create an announcement issue by using the ASP.NET Core breaking change issue template.
\n- [ ] Link the breaking change announcement issue from this PR.
\n- [ ] Remove the needs-breaking-change-announcement label.

[Tratcher]

• Create an announcement issue by using the ASP.NET Core breaking change issue template.

Please draft the announcement here in a PR comment for review.

We likely don't need to mention this in the blog, it's low usage.

[JamesNK]

LGTM. Remember to add a breaking change notification.

[mitchdenny]

@Tratcher proposed wording for announcement:

In .NET 8.0 the ASP.NET Core team is deprecating the ConcurrencyLimiterMiddleware and associated methods and types (e.g. UseConcurrencyLimiter(...)). This package will be removed in .NET 9.0.

Developers requiring rate limiting capabilties should switch to the newer and more capable rate limiting middleware that was introduced in .NET 7.0 (e.g. UseRateLimiter(...)). The .NET 7.0 rate limiting API includes a concurrency limiter along with several other rate limiting algorithms that you can apply to your application.

For more information on rate limiting in ASP.NET Core see:
https://learn.microsoft.com/aspnet/core/performance/rate-limit

Should I just go ahead and create the breaking change issue?

[JamesNK]

That looks good for a summary. Go ahead. Here is an example of obsoleting an API announcement: aspnet/Announcements#458

btw, lock the issue on the announcement repo. I you don't, then random people comment on it and it sends out more notifications 😄

[gewarren]

Is there a reason ASP.NET doesn't use custom obsoletion IDs like core .NET libraries? https://learn.microsoft.com/en-us/dotnet/fundamentals/syslib-diagnostics/obsoletions-overview

[ghost]

Hi @gewarren. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.

[mitchdenny]

/cc @davidfowl for his answers to this:

Is there a reason ASP.NET doesn't use custom obsoletion IDs like core .NET libraries? https://learn.microsoft.com/en-us/dotnet/fundamentals/syslib-diagnostics/obsoletions-overview

[ghost]

Hi @mitchdenny. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.

[Youssef1313]

Removing needs-breaking-change-announcement.

This was announced in aspnet/Announcements#502