How does the dispatcher flush do invalidation rather than deletion?

Avatar

Avatar

James_Appleby

Avatar

James_Appleby

James_Appleby

15-09-2020

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?

View Entire Topic

Avatar

Avatar

Bruce_Lefebvre

Employee

Avatar

Bruce_Lefebvre

Employee

Bruce_Lefebvre
Employee

15-09-2020

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-...