feat(iroh-dns-server)!: eviction of stale zonestore entries #2997
Conversation
Also fix some stupid bugs
# Conflicts: # Cargo.lock # iroh-dns-server/Cargo.toml # iroh-dns-server/benches/write.rs # iroh-dns-server/src/store/signed_packets.rs
|
Documentation for this PR has been generated and is available at: https://n0-computer.github.io/iroh/pr/2997/docs/iroh/ Last updated: 2024-12-05T14:31:09Z |
rklaehn
changed the title
a second table that has time -> Set<Key>
|
Aside from the messed up git history I guess :D |
There was a problem hiding this comment.
There is quite a lot of code just to expose these config options. We could also omit this and just use reasonable defaults.
I think the options are neat, but I'll let @Arqu comment more on these preferences.
Some slight worry about keeping invariants, other than that, I think this looks good :)
EDIT: I wrote that comment before Arqu commented, seems like it's fine by him :) 👍
since time is probably unique in 99.9% of all cases, it does not make a diff...
| if existing.more_recent_than(&packet) { | ||
| res.send(false).ok(); | ||
| continue; | ||
| } else { | ||
| replaced = true; | ||
| // remove the packet from the update time index | ||
| tables.update_time.remove(&packet.timestamp().to_be_bytes(), key.as_bytes())?; |
There was a problem hiding this comment.
should this be tables.update_time.remove(&existing.timestamp().to_be_bytes(), key.as_bytes())?; (existing instead of packet)?
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
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