You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(iroh-dns-server)!: eviction of stale zonestore entries (#2997)
## Description
Configurable eviction of stale zonestore entries.
This works by taking a snapshot of the database in regular intervals and
checking if a record is possibly expired. For all possibly expired
records a fire and forget message will be sent to the io write actor to
check again. The actor will check the expiry again (entry could have
been renewed since the last snapshot) and then deletes it if the final
check confirms expiry.
Between expiry checks there is a configurable delay, so the thread is
not constantly spinning checking for expiry.
We use a second thread since we don't want to block writing new entries
by sifting through old entries.
## Breaking Changes
- struct config::Config has a new field zone_store
- struct metrics::Metrics has a new field store_packets_expired
## Notes & open questions
Note: there are two ways to do eviction. One is to carefully keep track
of the time for each entry by having a second table that has (timestamp,
key) as the key and () as the value. Then you could just evict without
doing a full scan by sorting by time ascending.
The downside of course is that you need an entire new table, and you
need to update this table every time you update an entry (delete (old
time, id), insert (new time, id).
~~So I decided to just do a full scan instead for simplicity. We can
change it if it becomes a problem.~~
~~Hm, maybe we should avoid the full scan after all. I can imagine the
thing being a bit less responsive than usual while the scan is ongoing.
Another idea would be to have an "event log" where you just store (time,
id) -> () and then use that to look for eviction *candidates*. Don't
bother cleaning up this event log on every update.~~
I have now implemented a second table. It is a multimap table from
timestamp to id. This gets updated on every write (slight perf downside
here), and can be used to scan for evictions without having to do a full
scan.
There is quite a lot of code just to expose these config options. We
could also omit this and just use reasonable defaults.
## Change checklist
- [ ] Self-review.
- [ ] Documentation updates following the [style
guide](https://rust-lang.github.io/rfcs/1574-more-api-documentation-conventions.html#appendix-a-full-conventions-text),
if relevant.
- [ ] Tests if relevant.
- [ ] All breaking changes documented.
---------
Co-authored-by: dignifiedquire <me@dignifiedquire.com>
Co-authored-by: Asmir Avdicevic <asmir.avdicevic64@gmail.com>
0 commit comments