-
-
Notifications
You must be signed in to change notification settings - Fork 104
Added support for verifying the allow limit without incrementing it. #8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
// Verify reports whether an event with given name may happen at time now. | ||
// It allows up to maxn events within duration dur. | ||
// The difference for the Allow method is that this method does not increment usage. | ||
func (l *Limiter) Verify(name string, maxn int64, dur time.Duration) (count, reset int64, allow bool) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This package is designed after https://godoc.org/golang.org/x/time/rate and in that package I see method AllowN
. So what do you think about replacing Verify
with AllowN(name string, maxn int64, dur time.Duration, n int64)
? Then you can use AllowN("hello", 100, time.Minute, 0)
to get current rate limit.
@@ -102,3 +131,22 @@ func (l *Limiter) incr(name string, dur time.Duration) (int64, error) { | |||
rate, _ := incr.Result() | |||
return rate, err | |||
} | |||
|
|||
func (l *Limiter) get(name string) (int64, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think instead of get you should modify incr
to accept n int64
and use it as incr(name, dur, 0)
to get value without incrementing it.
}) | ||
|
||
rate := int64(0) | ||
rateStr, _ := getCmd.Result() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can use getCmd.Int64()
as a shortcut here.
if dur > time.Hour { | ||
t.Fatalf("got %s, wanted <= %s", dur, time.Hour) | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These 3 tests are too verbose... can you try to replace them with table-driven tests? https://github.com/golang/go/wiki/TableDrivenTests
Fixed. Hope it's better now! |
// when Redis Server is not available. | ||
// NewLimiter creates a limiter that controls how frequently events | ||
// are allowed to happen. It uses redis to store data and fallbacks | ||
// to the fallbackLimiter when Redis Server is not available. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know you did not change, but as remindment to myself this comment should be on struct Limiter
if err == nil { | ||
allow = count <= maxn | ||
} | ||
|
||
return count, reset, allow | ||
} | ||
|
||
// Allow reports whether an event with given name may happen at time now. | ||
// It allows up to maxn events within duration dur. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can just say Allow is shorthand for AllowN(name, max, dur, 1).
@@ -1,12 +1,12 @@ | |||
package rate // import "gopkg.in/go-redis/rate.v4" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please revert?
Looks much better - thanks. I am going to merge this tomorrow with few edits. |
Merge and released as v4.0.0. Thanks for contribution. |
This PR adds the capability to verify the limits without incrementing them. This is very useful in my use case where I have one route that is rate limited and another one that uses the limit value for additional computation.
I also changed the places where the repository was mentioned in order for my pull request to be compatible with your codebase (otherwise there would be imports to github.com/heynemann/rate).
Feel free to ask me to modify my code in order to get this merged.
Thanks for the great work.