Need help in Rate Limiting Option in Ocelot

[anonimousspider]

We are facing some issue in rate limiting policy, whenever we try to apply below mentioned cases:

Case1

When we are trying to add RateLimiting with same value for Period and periodTimeSpan and it is working properly

"RateLimitOptions": {
  "ClientWhitelist": [],
  "EnableRateLimiting": true,
  "Period": "1s",
  "PeriodTimespan": 1,
  "Limit": 1
}

Case 2

When we are trying with different values of period and PeriodTimeSpan as mentioned below: but is not working

"RateLimitOptions": {
  "ClientWhitelist": [],
  "EnableRateLimiting": true,
  "Period": "60s",
  "PeriodTimespan": 30,
  "Limit": 10
}

Could you please guide on the same?

[raman-m]

Hello, @anonimousspider !

or can you expedite the fix for this issue before the planned release?

The fix is scheduled for the Spring'24 release, which is currently underway. A faster merge into the release branch is possible with your contribution. Presently, PR #1592 is assigned to me as the original author is no longer maintaining it. On the other hand, I am preoccupied with significant developments, including the delivery of approximately 10 PRs across both milestones. The sole method to expedite this process is through your contribution.

---

there an alternative approach to achieving the same functionality

Certainly! There are two potential scenarios to circumvent faulty behavior:

• Utilize Ocelot's Own Implementation, but be aware of the existing bug that prevents specifying PeriodTimespan > Period, which is the issue in your described failed Case 2. To ensure proper behavior, define PeriodTimespan < Period, for instance, PeriodTimespan=9s and Period=10s.
• Opt for the ASP.NET Core Implementation instead of Ocelot's Own Implementation. This approach allows you to set global settings for all routes, offering the simplest migration path. For individual route settings, you would need to create a middleware or a delegating handler and implement the specific settings for each route.

---

As checked that this issue is already under development on ticket reference mentioned below #1590

Additionally, there is another ticket, #1975, for which I have suggested a temporary workaround that can be found here:
#1975 (comment)

This should serve as an interim solution to the problem.

[raman-m]

Duplicate of #1590 which may be fixed by #1592
Duplicate of #1975

[sberwal]

Hi Raman

Is there a timeline for this fix to be released for #1592 as part of Annual 2023 release.

This is something we also are looking for this fix to come out as it’s a critical usecase for us.

Thanks
S

[raman-m]

PR #1592 has been given priority and shifted to the current monthly release, namely March-April '24.
Consequently, the delivery is expected to be expedited.

[sberwal]

Thanks 👍