Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Invalidate cache on new Azks epoch #148

Closed
afterdusk opened this issue Feb 11, 2022 · 0 comments · Fixed by #150
Closed

Invalidate cache on new Azks epoch #148

afterdusk opened this issue Feb 11, 2022 · 0 comments · Fixed by #150
Labels
enhancement New feature or request

Comments

@afterdusk
Copy link
Member

In a distributed deployment, the cache may contain stale records. We want the cache to be invalidated when a new Azks record with a higher epoch number is detected, so that stale HistoryTreeNodes are not used to generate proofs. This involves remembering the epoch of the Azks record in the cache, and at TTL expiration checking it against the newly fetched Azks record to see if the epoch number changed. If it has, the entire cache should be dumped.
@afterdusk afterdusk added the enhancement New feature or request label Feb 11, 2022
slawlor added a commit that referenced this issue Feb 22, 2022
@slawlor
Add the ability to periodically poll for changes to the AZKS record, …
091acab 
…and when a change in epoch is detected, flush the cache

Additionally add support for a read-only directory which cannot perform "write" operations to the directory

Resolves: #149, #148
@slawlor slawlor mentioned this issue Feb 22, 2022
Merged
@slawlor slawlor linked a pull request Feb 22, 2022 that will close this issue
Add the ability to periodically poll for changes to the AZKS record and invalidate cache #150
Merged
slawlor added a commit that referenced this issue Feb 25, 2022
@slawlor
Add the ability to periodically poll for changes to the AZKS record a…
3aeb12d 
…nd invalidate cache (#150)

* Add the ability to periodically poll for changes to the AZKS record, and when a change in epoch is detected, flush the cache

Additionally add support for a read-only directory which cannot perform "write" operations to the directory

Resolves: #149, #148

* Apply clippy lints and fix test infra (mysql_async version bump)

* rustfmt

* Addressing @afterdark 's comments around cache access and flushing potential races.

Adds a multi-reader, single-flusher protection around cache operations. Additionally, readers need to poll for AZKS changes or the cache will never update the AZKS object as it's now cached forever until a manual flush operation is done.

* Missed clippy's

Co-authored-by: Sean Lawlor <seanlawlor@fb.com>
@slawlor slawlor mentioned this issue Jun 1, 2022
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request
Projects
None yet
Milestone
No milestone
1 participant
@afterdusk