How does the dispatcher flush do invalidation rather than deletion?

[James_Appleby]

Normal behaviour for a dispatcher is to delete the target file and then invalidate parent levels (if ResourceOnly isn't set).  The deletion is documented here: https://docs.adobe.com/content/help/en/experience-manager-dispatcher/using/configuring/page-invalida...

In ACS Commons there is a tool called Dispatcher Flush UI.  https://adobe-consulting-services.github.io/acs-aem-commons/features/dispatcher-flush-ui/index.html. When using this, it seems to be possible to invalidate the target file, rather than delete.

Invalidation is preferred in my current deployment.  If AEM is unavailable we would like to serve stale content rather than an error.  This is only possible if the dispatcher retains an expired file rather than deleting it.

I have observed the OOTB flush instruction delete the file and the ACS Commons tool not delete it and then replace it on the next call. Therefore I believe there is some setting to allow invalidation over deletion. I can't find any documentation on this, nor locate it in the ACS Commons source code. Do you know how the request varies to allow this to function?

[Bruce_Lefebvre · Accepted solution]

Hi @James_Appleby,

Are you familiar with the concept of a Re-fetching Flush? The "Optimizing the Dispatcher cache" doc has details on this approach: https://helpx.adobe.com/ca/experience-manager/kb/optimizing-the-dispatcher-cache.html#refetching-flu...

We've written a few lab-format dispatcher experiments to raise awareness about some of the dispatcher's features, and the first one is on the "Effect of Re-fetching Dispatcher Flush": https://github.com/adobe/aem-dispatcher-experiments#experiments 

This approach in combination with setting `/serveStaleOnError "1"` in the dispatcher's /cache rules might cover your use case nicely.

Yes, this feature still uses the standard flush agent URI (http://host:port/dispatcher/invalidate.cache), but changes the HTTP method to POST and uses the custom serialization type which is implemented in this example code (and intended to be customized for your own use case): https://github.com/cqsupport/webinar-dispatchercache/blob/master/src/refetching-flush-agent/refetch-...

[James_Appleby]

Thank you Bruce. Could you clarify something for me please? Is this feature just using the refetch within the regular /dispatcher/invalidate.cache call? The feature you've documented should solve 90% of our problems, but we also have a bespoke script call to /invalidate.cache. If using the refetch by posting paths also causes it to overwrite rather than delete, it should solve 100% of the problem.

[Bruce_Lefebvre]

Yes, this feature still uses the standard flush agent URI (http://host:port/dispatcher/invalidate.cache), but changes the HTTP method to POST and uses the custom serialization type which is implemented in this example code (and intended to be customized for your own use case): https://github.com/cqsupport/webinar-dispatchercache/blob/master/src/refetching-flush-agent/refetch-...