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

Figure out sub-second file update cache busting #21

Open
Munter opened this issue Sep 29, 2015 · 8 comments
Open

Figure out sub-second file update cache busting #21

Munter opened this issue Sep 29, 2015 · 8 comments

Comments

@Munter
Copy link
Owner

Munter commented Sep 29, 2015

File systems only track update time with second granularity. So some times this interaction happens:

time    0: FILE_UPDATE1
time    0: FILE_READ + CACHE_WRITE: FILE_UPDATE1
time  100: FILE_UPDATE2
time 1000+: FILE READ -> CACHE_HIT: FILE_UPDATE1

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

@unwitting
Copy link
Collaborator

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?

@Munter
Copy link
Owner Author

Munter commented Sep 29, 2015

Updated to make it more obvious what is happening.

@unwitting
Copy link
Collaborator

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?

@Munter
Copy link
Owner Author

Munter commented Sep 29, 2015

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

@unwitting
Copy link
Collaborator

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.

@unwitting
Copy link
Collaborator

Is this bug the reason for the 1200ms timeouts in the test files?

@marijnh
Copy link

marijnh commented Feb 10, 2016

I've worked around this in the past by watching the file and invalidating the cache when something happens to it.

@Munter
Copy link
Owner Author

Munter commented Jul 23, 2016

This should be fixed by implementing https://github.com/assetgraph/skrin which has a bit more intelligent cache handling

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants