Is your feature request related to a problem? Please describe.
I'm experiencing limitations when setting up daily rate limits with Spring Gateway's Redis Rate Limiter. According to the documentation:
Rate limits below 1 request/s are accomplished by setting replenishRate to the wanted number of requests, requestedTokens to the timespan in seconds, and burstCapacity to the product of replenishRate and requestedTokens.
For instance, replenishRate=1, requestedTokens=86400 (for a full day in seconds), and burstCapacity=86400 would theoretically enable a 1 request/day rate limit.
However, in the current implementation, burstCapacity is limited to the maximum int value. This means that for a daily rate limit, we can't specify more than 2147483647 / 86400 ≈ 25,000 requests. This constraint makes it challenging to set higher daily limits, which are often required for applications with high usage.
Describe the solution you'd like
I would like burstCapacity to be stored as a long instead of an int. Since burstCapacity does not involve multiplication in the rate-limiting Lua script logic, switching to long should not introduce any risks (such as overflow) but would allow for larger rate limits.
Is your feature request related to a problem? Please describe. I'm experiencing limitations when setting up daily rate limits with Spring Gateway's Redis Rate Limiter. According to the documentation:
For instance,
replenishRate=1,requestedTokens=86400(for a full day in seconds), andburstCapacity=86400would theoretically enable a 1 request/day rate limit.However, in the current implementation,
burstCapacityis limited to the maximumintvalue. This means that for a daily rate limit, we can't specify more than2147483647 / 86400 ≈ 25,000requests. This constraint makes it challenging to set higher daily limits, which are often required for applications with high usage.Describe the solution you'd like I would like
burstCapacityto be stored as alonginstead of anint. SinceburstCapacitydoes not involve multiplication in the rate-limiting Lua script logic, switching tolongshould not introduce any risks (such as overflow) but would allow for larger rate limits.