-
Notifications
You must be signed in to change notification settings - Fork 503
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
Big Kahuna: Do cache fills synchronously #290
Comments
@arschles if you haven't started working on it already, I've already written some of the code for how you described |
@marwan-at-work I'd love that! I'm gonna work in increments starting with moving the fetcher logic in #291 and then to putting synchronous fetches into each endpoint, so I'll skip the |
We're breaking this up into a few pieces:
Edit #291 is in, but #291, #314 and #316 are closed out, in favor of doing all the cleanup work in #335 |
This patch shows how we could synchronously fill in storage when the proxy or registry receive a request to '.../version.info' and the package isn't in storage. Requires gomods#291 Part of gomods#290
Edit: see #290 (comment) |
We've had some discussion about whether to do cache fills synchronously or asynchronously. We've discussed how we can make a
vgo get
call still succeed if we do cache fills asynchronously (and return a 404 to the user), and created golang/go#26334 to discuss a possibility.I've mostly argued for asynchronously filling caches until now, but I'm changing my mind because I think doing so makes the CLI (
vgo
, soon to be Go modules in 1.11), the architecture, and the conceptual model of both the registry and the proxy easier to grasp.Here's exactly what I'm suggesting on the servers:
GET /list
request, we return only the tags from the upstream. No fetchinggo.mod
or other assets/vX.Y.Z.info
,vX.Y.Z.info
orvX.Y.Z.zip
request, we fetch and store all three assets and return the appropriate oneWith this machinery in place, the CLI won't need to consider whether to "back off" to the VCS. If it's not in the proxy/registry, it doesn't exist, and that invariant makes golang/go#26334 no longer necessary.
The text was updated successfully, but these errors were encountered: