Cached value #288
Cached value #288
Conversation
alexsnaps
force-pushed
the
cached-value
branch
2 times, most recently
from
6df11ef to
aad9e79
Compare
| - user_id |
There was a problem hiding this comment.
Wherever (probably I) that got removed, that was a mistake
| @@ -5,22 +5,19 @@ use std::time::{Duration, SystemTime, UNIX_EPOCH}; | |||
| #[derive(Debug)] | |||
| pub(crate) struct AtomicExpiringValue { | |||
| value: AtomicI64, | |||
| expiry: AtomicU64, // in microseconds | |||
| expiry: AtomicExpiryTime, | |||
There was a problem hiding this comment.
I think encapsulating that behavior made sense, regardless of the change... but now that I needed reusing that very same thing... it was time ;)
| self.expiry.duration() | ||
| } | ||
|
|
||
| #[allow(dead_code)] |
There was a problem hiding this comment.
This is annoying, it's dead code when compiling for wasm... I don't think we should fail the build when that happens tho. Dead code for that target is fine, it's all DCE'd anyways...
| let cache_ttl = self.ttl_from_redis_ttl( | ||
| redis_ttl_ms, | ||
| counter.seconds(), | ||
| counter_val, | ||
| counter.max_value(), | ||
| ); |
There was a problem hiding this comment.
This probably should be folded in the CachedCounterValue type... more specifically its constructor
There was a problem hiding this comment.
Makes more sense to use moka's cache and keep track of the counter values with the AtomicExpiringValue, also, a nice refactor done to that one. This changes drastically the way I'll be updating the cache once I get the updated values from Redis, so hopefully will be merged soon :)
This fixes the issue when a partition lasts longer than a counter's time window and all the increments from the previous window get batched with the current one, resulting in limiting the requests too early