-
-
Notifications
You must be signed in to change notification settings - Fork 74
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
Provide an easy way to implement per-entry TTL and TTI #300
Comments
starting with things that can expire
I define TTI & TTL tables for per-item expirations. Each contains constants that are based on the current environment.
Tables referenced by the Expiry trait
Expiry trait iimplementation
|
As another example, in Symbolicator each cache item is carrying an explicit |
it would be great if we can call a function to set a ttl for a specific key like redis: https://redis.io/commands/expire/ use case: i'm building an in memory rate limiter using moka as the kv store. The high level code is:
I need to add a mutex because if concurrent requests hit my service asking to increment a counter (implementing token bucket in my case), i need to process the requests serially so I can keep track of the right state. Right now, best I can do is store the ttl in the RateLimit struct and use expire_after_read. Ideally I would use the expire_after_update but updating the struct this way is not recognized as an update to the kv so the new ttl won't be picked up. With the feature i'm requesting, I'm thinking i would be able to do something like:
This way I also avoid storing the ttl in the struct as I can derive it from other states i'm not showing here. Maybe there is a better way to do what I want without the "feature i'm requesting"? |
Thank for the feedback! We had similar discussion for I have not had chance to finalize the spec of |
thank you for the context! |
Just FYI, I brushed up the |
Now that |
Provide an easy way to implement per-entry TTL and TTI using the
Expiry
trait.While
Expiry
trait provides great flexibility to implement different per-entry expiration policies, its API is a bit low level and some users are having problems using it to implement simple policies like per-entry time-to-live and time-to-idle.We could simply put an example struct to the
examples
directory. Or we could make the example struct generic enough and put it undermoka::expiry
module.The text was updated successfully, but these errors were encountered: