Flush DAM assets | Dispatcher cache

Issue

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.

Solution

CQ5.3, CQ5.4, and CQ5.5

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

agent:<flush_agent_id>

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:

agent:flush1,agent:flush2

CQ5.6 and later

ملاحظة:

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.