Best way to invalidate all caches after deployment

[sheadawson]

Hi just having a go with this module on a project, loving it so far. Just wondering if there is a "best way" to flush/invalidate all caches in an event such as a deployment? ie. in a BuildTask

[stecman]

"Best" really depends on your deployment process, but if you can run shell commands in your deployment process, this is probably the easiest method:

$ framework/sake cache-include/clearAll

Alternatively, you could add a build task or logic somewhere that gets CacheInclude from the Injector and calls its flushAll method.

[sheadawson]

Excellent yeap sake cache-include/clearAll is perfect.

Much of the code in this module is new to me so it's a little hard digging around for my own answers. Would be cool to have some doc in the readme for clearAll. And possibly also for flushAll with an example of how to get CacheInclude from the Injector

[camspiers]

That is a really good point @sheadawson, there is no docs for the cli controller. I'll create a task

[camspiers]

I created task #22

[TheBnl]

I'm experiencing issues clearing the cache trough this command, though i'm not sure if it is an issue or not. I am curious if other people are experience the same situation and how they coop with it.

On one project where i use cacheinclude i get into the situation where i get a really bloated "cache" folder in the cache include directory. So bloated that i cannot simply remove it by rm -R i have to resort to tricks that bypass the "Argument list too long" error.

Every time i'm doing an update i need to somehow remove the cache folder before i can even execute a dev/build. This becomes problematic doing regular updates.

What i find strange, but maybe that's because i don't understand the full inner workings of the clear command, is that i run the sake cache-include/clearAll command every week to prevent the folder for getting to this state. Is that because the clear command only removes references and not the actual files?

Hope there is a solution to this problem, i am thinking about combining the clearAll command with a rm command that removes the actual files so the files and references get reset. But again i don't know if the clearAll command is supposed to delete the actual files.

[stecman]

Hey @TheBnl, you're encountering the issue described in #18 and #17.

It can get into this broken state because each cache block config uses its own single item in the cache to index which other keys belong to it (so they can be cleared when you save something related in the CMS). There's a race condition between the fetch and write here.

The workaround at the moment is to clear the cache backend manually when this is encountered (rm -r using the file backend). The solution is either to introduce some cache-specific locking that works for each backend, or change the design to avoid a locking problem.

[nfauchelle]

Afternoon folks.

If I try and run cache-include/clearAll on the CLI I can see it comes back with a "page not found". The caching is working and getting cleared when I save the page, it'd just be nice to trigger it manually.

Does that command / path rely on silverstripe-cacheinclude-manager? or does some route need to be exposed.

[stecman]

@nfauchelle it looks like the clearAll action was removed in the upgrade for SilverStripe 4 (here) and replaced with a build task.

Starting in CacheInclude 5.0, the way to do this from the command line would be:

./vendor/silverstripe/framework/sake /dev/tasks/CacheIncludeClearTask all=1