ACS Commons Dispatcher Flush Agent breaks Replication:Error while replicating content com.day.cq.replication.AccessDeniedException | Community
Skip to main content
dewanshis189253
dewanshis189253
January 21, 2019

ACS Commons Dispatcher Flush Agent breaks Replication:Error while replicating content com.day.cq.replication.AccessDeniedException

  • January 21, 2019
  • 1 reply
  • 3333 views

Hi Team,

I am using AEM Version: 6.4 and ACS Commons : 3.18.2 and have written Dispatcher Flush Rules using ACS Commons Configuration. I am getting below error and Replication breaks while replicating pages

Dispatcher Flush Rules :

  • /etc/packages/(.+)/.*=/etc.clientlibs/$1&/etc.clientlibs/common  
  • /apps/(.+)/clientlibs/.*=/etc.clientlibs/$1

Please help me on this.

Thanks

Dewanshi

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

1 reply

Gaurav-Behl
Gaurav-Behl
Level 10
January 21, 2019

If you use ACS flush agent, then you would need to configure appropriate ACLs for 'acs-commons-dispatcher-flush-service' user mentioned in docs.

Check if 'acs-commons-dispatcher-flush-service' user has read access on the content path that you are trying to flush.

On a side note, the flush rules doesn't seem to be appropriate to me. Please validate/fix, if required. 

    dewanshis189253
    dewanshis189253Author
    January 21, 2019

    Hi Gaurav,

    Thanks for your response . I have checked that user acs-commons-dispatcher has read access. Please find below screenshot.

    Above mentioned dispatcher rules working fine in DEV ,So I don't think that dispatcher flush rules are inappropriate.

    Thanks

    Dewanshi

      U
      user21583
      Level 2
      December 24, 2021

      Could you share the error details?

      This screenshot mentioned the error as 'insufficient permissions/access denied exception' on a specific path. Hence, the first step to debug is check the permissions of 'acs-commons-dispatcher-flush-service' and 'replication-service' service-users on those paths. Since you've configured flush rules, it doesn't harm to check the ACLs on other paths mentioned in rules. Could you validate that it has access to write/delete nodes as well?

      I'm not able to understand if this is a flush/invalidation agent then why is it trying to build the content for replication. Could you share the configurations of flush/invalidation agents and replication agents. Could you share more details from dispatcher.log/flush agent's log?

      I don't want to get hung up on the flush rules but when it comes to /etc/packages/(.+)/.*=/etc.clientlibs/$1, I've a question-

      • Is this 'package_name' that appears in /etc/packages/(.+) a static/constant folder name or does it get modified too often? If its dynamic then it could potentially be an issue.

      You may try to remove certain paths one by one to narrow down on the rootcause. You may share more logs that might provide some clues.

      Alternatively, you may want to log a ticket with DayCare or ACS Commons for this issue and wait for their response.


      Hi @gaurav-behl 
      Hope you're doing great!

      Would like to know more on this issue, like what was the solution provided by day care?
      We're facing similar issue where we have given all the access to acs flush service and replication-service, we are calling dispatcherFlusher.flush , whenever we want to invalidate a particular set of pages.

      Thanks!
      Sagar

        Terms & ConditionsAccessibility statement

        Loading footer...