How to Automatic Dispatcher Cache Invalidation in AEM - Part 2

The method described in Part 1 post allows the author instance to notify the dispatcher when a page has been modified. But there are a couple of potential issues with this method that should be pointed out. The documentation at http://dev.day.com/docs/en/cq/5-5/deploying/dispatcher/page_invalidate.html

state:
The Dispatcher must be reachable from the authoring instance. If your network (e.g. the firewall) is configured such that access between the two is restricted, this may not be the case.
Publication and cache invalidation takes place at the same time. Depending on the timing, a user may request a page just after it was removed from the cache, and just before the new page is published. CQ now returns the old page, and the Dispatcher caches it again. This is more of an issue for large sites.

One of the ways around the second issue is to have the publish instance(s) notify the dispatcher of the change, rather than the author notifying. This way, the publisher will definitely have received the change before the dispatcher is signaled to invalidate the cache.

To accomplish this, the method is virtually identical to my previous post, but instead of creating the agent under Agents on the author, you still create the agent on the author instance, but this time under Agents on publish.

Log into your author instance, and open the Tools console. Open the Replication tree in the navigation pane and expand the Agents on publish branch.



Select the Dispatcher Flush replication agent, click Copy, then Paste. Repeat this for each Dispatcher you want to create a flush agent for.



Double click the newly created agent you want to edit. It should open in a new tab/window with the details of the replication agent. Once opened, click the edit button and rename the agent on the Settings tab if desired.

On the Transport tab, update the URI to the server and port of the dispatcher Apache (or whatever web-server software you use) installation, ensuring to leave the remainder of the URI as /dispatcher/invalidate.cache



Open the Triggers tab and ensure that the On Modification checkbox is selected, along with any other triggers required.



Click OK to save the configuration, then click the Test Connection link to ensure the agent is configured correctly. If configured correctly, clicking the Test Connection should do nothing, as this is a Publish agent and you’re on an Author instance. Edit the agent again and check the Enabled checkbox on the Settings tab, and then OK to save. Go back to your Tools console, and Activate the agent(s).



If you log into the Publish instance(s) that you’re replicated the agents to, you should be able to use the Test Connection functionality now to ensure they are configured correctly.

Now, when you activate/replicate content from Author to Publish, the call to invalidate the cache will come from the Publisher after it’s received the changes from the Author, and the potential race condition is mitigated.