In my previous post about Automatic Dispatcher Cache Invalidation in CQ5, I only told half the story. The method described in that 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 take 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 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 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.
I've been a developer for over a decade, working with a varied range of products. I'm also an Adobe Certified Expert AEM 6.0 Developer, CQ 5.6 Component Developer, ColdFusion, and Advanced ColdFusion, and a Certified Scrum Master.
Code Monkey 
Pingback: CQ5 Gotchya: Cache Invalidation from Publish Agent | Code Monkey
Hi, can you tell me if i just change any jpg file in author instance and activate it. Will the new jgp file get replaced in the document root of cache folder of apache? I don’t see that happening
Hi sivakumar,
This depends on your setup I guess. Firstly, what version of CQ are you using? Prior to AEM (CQ5.6), the cache invalidation is only done when nodes of type cq:Page are activated (See my post Cache Invalidation from Publish Agent). Also remember that the file will only be put in the cache in the first place if the correct rules are set in the dispatcher.any file, and also the new file will only replace the old file after someone requests the file, not immediately after activation.
Hi Kristen, I saw your post in the Adobe community forum on issues with Dispatcher flush. Did you manage to solve it?
Hi Jin,
I opened a Daycare ticket for it while I was creating my own custom solution. The outcome of the ticket was that it’s a known issue in CQ5.5 and has been addressed in CQ5.6. It would take over a month for the engineers to back-port a solution to 5.5, so I needed to use my custom solution: Install the package to allow DAM asset activation to invalidate the cache (http://helpx.adobe.com/cq/kb/HowToFlushAssetsPublish.html), and then call the same script from that package with my own custom workflows that are triggered from modifying files under branches such as /etc/designs/myapp.
When I can squeeze in some time, I’ll write up the solution in another post!
Hi Kristian,
Have u worked integration of Solr search with AEM5.6, if yes can you please share me the Demo package ,thanking you in advance,
Hi Chandrapal,
No, unfortunately I’ve not dealt with Solr integration.
I am facing issue with cache on cq5 Apache, when ever cq5 application have some change i have to manually clear the cache , more over in between Apache and cq5 we have f5 load balancer in place . So is it possible to invalidate cache when F5 is in between Apache and cq5 .
Hi Rakesh,
Having a load balancer between your dispatchers and publish instances is not uncommon, and this should not prevent your CQ server from invalidating the cache provided they are set up correctly. How are you trying to invalidate the cache?
Hi Kristian,
Currently I am using CQ5.5 .Based on the user access right 1 extra field should be appeared
under 1 topnavigation field. So, I have implemented the logic and restrict the field to don’t appear under that topnavigation for the user, those don’t have access for it . Once I dry run and activate, every thing is working properly and replicate it properly in publish instance. But, after certain ammount of time the field has appeared again for the user, those don’t have access for it
in publish instance.
Hi Debal,
This is hard to debug given the information provided. I suggest you post the issue on the official Adobe Experience Manager forum. If you reply to this with a link to the forum topic, I’ll see if I can help you out.
Hi Kristian,
Thanks for your reply. Able to resolve that issue.
Hi Kristian, Could you please tell me why do we need to create publish agent from author instance and then replicate to publish? will it not solve this issue if we directly create agent from publish instance itself? https://dev.day.com/docs/en/cq/current/deploying/dispatcher/disp_domains.html#Configuring the Dispatcher Flush replication agent
Hi Sam,
There’s a couple of reasons for this. First of all, as a general rule you should only ever create content (remember, everything is content, even agents such as this) on an Author instance, and replicate it to the Publish instances. The Authoring environment is for exactly that – authoring, while the Publish environment should not be used for authoring any content (social content excepted).
Secondly, what happens if you have multiple Publish instances? Then you would need to repeat the creation of the agents on all Publish instances manually. If you want to change some settings, you would need to manually do this on each Publish instance as well. If you create it on the Author instance and replicate it to the Publish instances, then this is a single source of truth for the agent, and all changes can be made in one place.
Thant makes sense, thanks for the clarification
Sam