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.

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

Only garbage collect action cache entries #65

Open
buchgr opened this issue Jan 12, 2019 · 5 comments
Open

Only garbage collect action cache entries #65

buchgr opened this issue Jan 12, 2019 · 5 comments

Comments

@buchgr
Copy link
Owner

buchgr commented Jan 12, 2019

The cache should only garbage collect action cache entries based on last access time. CAS entries should have a reference count and only be collected if they are no longer referenced by any cache entry.

@buchgr buchgr added this to the 1.0 milestone Jan 12, 2019
@bayareabear
Copy link
Contributor

Can we make an assumption that one CAS entry is only referenced by one ac entry, so that when we delete ac entry, we just delete all the CAS entries referenced by that ac entry?

@buchgr
Copy link
Owner Author

buchgr commented Jan 18, 2019

Can we make an assumption that one CAS entry is only referenced by one ac entry, so that when we delete ac entry, we just delete all the CAS entries referenced by that ac entry?

No that's generally not true. A blob is often referenced by thousands of action cache entries. I am currently implementing this feature and adding a reference count to each CAS entry. So we'll only evict a CAS entry when its no longer referenced.

@bayareabear
Copy link
Contributor

Then when PUT AC/CAS to server, Is the following sequence always guaranteed to ensure the server correctness:

  1. All the CAS entries referred by a AC are PUT to server first
  2. Then the AC entry is PUT to server

@bayareabear
Copy link
Contributor

Also, is it possible to let Bazel back off when it GET an AC entry returns 200 but the corresponding CAS is not found in the server? I found when this happens, bazel build may fail. The Bazel build requirement that CAS entry referred by AC entry always exist in the server causes two drawbacks:

  1. We have to keep track the reference count of CAS object for garbage collection
  2. For horizontal scale and load balancing, consistency among servers can be hard to maintain
    The ideal Bazel behavious is following:
    Every CAS entry can be tracked back to the corresponding AC that generate it. In case a CAS entry referred by an AC is missing, back track the AC entry and re-run the AC to regenerate the missed CAS entry. This immediately fix the two drawbacks mentioned above.

@mostynb
Copy link
Collaborator

mostynb commented Oct 22, 2019

Also, is it possible to let Bazel back off when it GET an AC entry returns 200 but the corresponding CAS is not found in the server?

This is implemented in my gRPC WiP in #97, and I filed #106 for a backwards-compatible solution for http.

@bayareabear ^

@mostynb mostynb removed this from the 1.0 milestone Jun 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants