To avoid potential timing conflicts during replication and parallel Dispatcher flushes issued from an author instance, a publish instance is configured to flush the Dispatcher cache via the replicate-on-modification trigger.
However, that replication of DAM assets doesn't lead to expected Dispatcher flush requests.
The replicate-on-modification functionality is currently only triggered for Page events, so DAM assets are ignored. Attached is a package to resolve this problem and contains the following:
- Flush Dispatcher wf-model, enabled for publish-runmode only
- custom ecma-script to initiate a Dispatcher cache flush
- wf-launcher to trigger above wf-model in case a DAM asset (its original rendition) has been modified
To install the package, upload it to the author instance and activate it across to the publish instances using the CQ Package Manager UI. The package gets automatically deployed and installed on the publish instances.
The package is now available on the package share ar this link.
See this link on statfileslevel setting.
The Dispatcher flush wf-model passes the default ID of the Dispatcher flush agent as process argument to the ecma-script to trigger the flush requests. If it differs in your environment, adjust the process argument of the "Flush Dispatcher'" workflow-step accordingly:
Optionally, you can configure it for multiple Dispatcher flush agent by separating the flush commands with a comma. Example:- flush1 and flush2 are the agent id of Dispatcher flush agents then in Dispatcher flush wf-model process argument specify as follows:
In CQ5.6 and later, the workflow-based solution above is no longer necessary.
You can instead handle the flush in the new "chain replication" feature. With this feature enabled, the dispatcher flush agent sends a flush request when a replication is received from author.
To enable it:
- Follow the steps here to create flushing agents on publish
- Then go to each of those agents' configuration and check the "Triggers" => "On Receive" box.