How does the dispatcher flush do invalidation rather than deletion? | Community
Skip to main content
Level 2
September 15, 2020
Solved

How does the dispatcher flush do invalidation rather than deletion?

  • September 15, 2020
  • 1 reply
  • 1715 views

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

 

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?

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by brucelef

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

 

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

1 reply

brucelefAdobe EmployeeAccepted solution
Adobe Employee
September 15, 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-flush

 

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

Level 2
September 15, 2020

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.