-
Notifications
You must be signed in to change notification settings - Fork 10
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
Figure out sub-second file update cache busting #21
Comments
Can I confirm - the second step - is that FILE_READ and CACHE_WRITE with the previously UPDATED value? Or the value from before the first step? |
Updated to make it more obvious what is happening. |
I'm still not that familiar with the library code sorry - how come UPDATE2 doesn't bust cache? At which level is the cache being managed? In our code, or FS code? |
UPDATE2 doesn't but the cache because the last update time is still within the same 1000ms. Since file systems don't track time at a fidelity better than seconds, the last update time is not different, so the cache is treated as fresh |
AH I see ok. The problem with your first solution, not trusting caches from within same second, is that people might try to use this in semi-production / small-scale production uses and rely on the cache to make sure performance isn't too bad. In that case they'll be getting >1 request per second and we'd be busting cache every time. I know it's a dev tool but if the cache is reliable then there's no reason why it can't work in situations like that. |
Is this bug the reason for the 1200ms timeouts in the test files? |
I've worked around this in the past by watching the file and invalidating the cache when something happens to it. |
This should be fixed by implementing https://github.com/assetgraph/skrin which has a bit more intelligent cache handling |
File systems only track update time with second granularity. So some times this interaction happens:
We need to change the caching algorithm so stale cache is not served in this situation. Possibly something about not trusting cache entries from within the same second, plus maybe a safety margin.
This error is especially prevalent with live reloading setups, since the file watch trigger will almost guarantee sub-second file reads when the file updates
The text was updated successfully, but these errors were encountered: