8 Replies Latest reply on May 25, 2013 5:31 PM by Kristian Wright

    Dispatcher Flush Agent on Publisher not invalidating cache

    Kristian Wright Level 1

      Hi all,

       

      We're having an issue with invalidating that cache apon activation/replication of content, but only from the Publish flush agent.  I've copied the default flush agent on the Publish instance, updated the URI to point to my dispatcher, and enabled the agent.  Clicking Test Connection shows a successful connection to the dispatcher.  Also, I can see that the .stat file has been created at the web root on the dispatcher (I'm not specifying a specific statsfile or a statsfile level in the dispatcher.any).  When I change a setting in the publisher flush agent and save it, or stop and start it, the .stat file is updated.  So I know the Publisher is able to correctly reach the dispatcher and pass along the invalidate message to update the .stat file.

       

      When I replicate a node from Author the Publisher, I see the following in the Publisher error.log:

       

      22.05.2013 04:23:23.241 *INFO* [ObservationManager] com.day.cq.wcm.core.impl.components.ComponentCacheImpl Detecting component change. invalidating cache.

      22.05.2013 04:23:23.245 *INFO* [10.20.30.40 [1369196603165] POST /bin/receive HTTP/1.1] com.day.cq.replication.impl.content.durbo.DurboImporter imported content in 79ms for durbo request on path: /apps/my-project/components/page/base/footer.jsp

      22.05.2013 04:23:23.245 *INFO* [10.20.30.40 [1369196603165] POST /bin/receive HTTP/1.1] com.day.cq.replication.impl.servlets.ReplicationServlet Processed replication action in 79ms: ACTIVATE of /apps/my-project/components/page/base/footer.jsp

       

      However when I check the dispatcher, I see that the .stat file has not had its timestamp updated.  I've also noticed that when I change the node and replicate it, the 'Detecting component change. invalidating cache.' log line above does not always appear in the log file - it appears only sometimes with the other 2 long lines.  This part seems random.

       

      In my testing, I've also created a Dispatcher Flush agent on the Author instance (after disabling the one on the Publish instance), and 100% of the time when I replicate the /apps/my-project/components/page/base/footer.jsp to the Publisher, the Author flush agent correctly updates the .stat file timestamp.  So I'm 100% confident that the file I'm editing is able to be cached, and that changing and replicating it does update the .stat file.

       

      Just never from the Publish flush agent!

       

      I've tried all combinations of trigger settings on the Publish agent to no avail.  I've also inspected the properties of the agent in CRXDE Lite, and I can't see anything that the Author agent has and the publish agent is missing!

       

      I've also tried creating the Publish agent by copying the default one from the tools console and updating the URI, creating a Publish agent on the Author and replicating it to the Publisher, and also creating it directly on the Publisher via curl calls - all of these methods seem to create a valid dispatcher flush agent on the Publisher that successfully connects to the dispatcher (confirmed by a successful 'Test Connection' click after creating), but none of them ever update the .stat file on the dispatcher after content replication.

       

      Any thoughts here on where else to look would be greatly appreciated!!

       

      Cheers,

      K

        • 1. Re: Dispatcher Flush Agent on Publisher not invalidating cache
          Jörg Hoh Adobe Employee

          Mark the checkbox "On Modification" on the "Trigger" Tab of your agent.

          • 2. Re: Dispatcher Flush Agent on Publisher not invalidating cache
            Kristian Wright Level 1

            Hi Jörg,

             

            In all my attempts I've ensured that the On Modification setting is on.  I've also confirmed on the node level that it contains the property 'triggerModified' and this is set to 'true'.

             

            Next step for me is to copy the working agent from the Author under agents.author to the Publisher under agents.publish and see if that works...

             

            Cheers,

            K

            • 3. Re: Dispatcher Flush Agent on Publisher not invalidating cache
              Jörg Hoh Adobe Employee

              Ah, of couse you need to configure your agent in the "agents.publish" then ... and don't forget to activate it.

              • 4. Re: Dispatcher Flush Agent on Publisher not invalidating cache
                Kristian Wright Level 1

                No joy I'm afraid.  Tried the following methods of creating the agent on the dispatcher:

                 

                • Creating an agent on the Author under agents.publish based on the default flush agent there, configuring and enabling it, and activating it to the Publish instance
                • Creating an agent directly on the Publish instance under agents.publish via cURL commands to create, configure and enable
                • Creating an agent directly on the Publish instance under agents.publish by copying the default flush agent there, configuring and enabling it
                • Replicating my working Author agent under agents.author to the Publish instance, and copying from the agents.author to agents.publish on the Publisher

                 

                None of these methods have successfully updated the .stat file when I activate/replicate a file.  As mentioned, they all pass the connection tests, and all update the .stat file when I enable them - I know they are able to update this file when they are in the mood!

                 

                The only time I've been able to succesfully update the .stat file when replicating content is by using an agent on Author which I do not want to do due to the known possible race conditions causing the re-caching of the older file.

                 

                CQ5.5 Service pack 2.

                 

                Thanks,

                Kristian

                • 5. Re: Dispatcher Flush Agent on Publisher not invalidating cache
                  Jörg Hoh Adobe Employee

                  Kristian,

                   

                  What are you activating, when you test your agent? A page or an asset or something else?

                   

                  I prefer the option 1 of your list. Make sure, that the agent has "on modification" as trigger (up to and including CQ 5.5) or "on receive" (CQ 5.6).

                  • 6. Re: Dispatcher Flush Agent on Publisher not invalidating cache
                    Kristian Wright Level 1

                    Hi Jörg,

                     

                    Thanks again for the reply.  I've just blown away all of my Author and Publish agents and recreated a new one via my first option above (which I believe is the recommended way to create a Publish flush agent).  I've been trying to flush some of my client libraries under /etc/designs/myproject, as well as components under /apps/myproject.  I hadn't tested a general Page replication until now.

                     

                    Turns out Page replication works correctly and the .stat file is updated by the Publish flush agent.  Anything that is not a page is not.  I've come across the package to allow DAM assets to be flushed on replication as well [1], and I see here that it states "The replicate-on-modification functionality is currently only triggered for Page events".  This would make sense then that the Page replication triggers the agent, and nodes under /etc or /apps do not.  I'm going to apply the package and see if it help solve the issue, even if just for the DAM, as I'll need these invalidated from the cahce when updated anyway.  If it ends up allowing other nodes than just those under /content/dam to be flushed, then perfect!  If not, then I'll look into extending the workflow of this package to achieve what I need.

                     

                    The confusing part of all of this is that my flush agent on Author correctly updates the .stat file for replications from /etc and /apps, and I don't see any noticable difference between the settings of it and my Publish agent.  I'm also unable to locate the workflow that the Author agent uses (I'm assuming it's a workflow) to invalidate the cache to pick that apart and see how it works.

                     

                    Will update my findings soon...

                     

                    Thanks,

                    Kristian

                     

                    [1] http://helpx.adobe.com/cq/kb/HowToFlushAssetsPublish.html

                    • 7. Re: Dispatcher Flush Agent on Publisher not invalidating cache
                      Jörg Hoh Adobe Employee

                      Yes, the problem with the "on modification" trigger set for a invalidation agent on publish is, that this is only firing when a cq:Page is modified (read: activated), but not for assets or other things. To mitigate this, the "on receive" trigger has been introduced with CQ 5.6, which does not care about the nodetype.

                       

                      If you need to work with CQ 5.5 or older, the support page you referenced describes the correct approach. If you have problems with that (or if some things are not clear, just contact Daycare.

                       

                      cheers,

                      Jörg

                      1 person found this helpful
                      • 8. Re: Dispatcher Flush Agent on Publisher not invalidating cache
                        Kristian Wright Level 1

                        Thanks for the update Jörg.

                         

                        We're running CQ5.5, so I'll patch it up and add my own triggers based on the DAM solution.

                         

                        This is obviously a known issue with CQ5.5 - are there plans to get this rectified in a service pack?  I would think that having more than only Page components and DAM assets invalidate the cache on replication via a publish flush agent would be something a lot of people require out of the box, hence the addition in 5.6...

                         

                        Cheers,

                        K