Highlighted

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

dewanshis189253

21-01-2019

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

1672693_pastedImage_1.png

Dispatcher Flush Rules :

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

Please help me on this.

Thanks

Dewanshi

Replies

Highlighted

Gaurav-Behl

MVP

21-01-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. 

Highlighted

dewanshis189253

21-01-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.

1672851_pastedImage_0.png

Thanks

Dewanshi

Highlighted

Gaurav-Behl

MVP

21-01-2019

Could you check the same permissions are applied to /content or /content<root>/au/en node where you see the error?

For first flush rule -

  • /etc/packages/(.+)/.*=/etc.clientlibs/$1&/etc.clientlibs/common  -- means the <group-name> and <package-name> under /etc/packages would be picked up for flushing. E.g.  /etc/packages/my_package/abc.zip  would be applied as /etc.clienlibs/my_package/abc.zip......

I'm not able to think of any reason to flush package name. The other path of /apps/<project-root>/ makes sense to me.

Since you are trying to flush /etc/packages and /apps/<project-root> paths, could you also validate if acs-commons-dispatcher-flush-service has access to /etc/packages and /apps/<project-root> per your use case?

Highlighted

jimzau

23-01-2019

I have the same problem as the OP.

Actually the flush rules makes sense - the first rule looks like it is flushing the CSS and JS resources upon replication, e.g.:

/etc/packages/my_package/abc.zip will be flushing /etc.clientlibs/my_package and /etc.clientlibs/common

As for permissions, in my instance, I can see that the acs-commons-dispatcher-flush-service has the correct access to /etc/packages and /apps/<project-root>

Do you have any other suggestions?

Highlighted

Gaurav-Behl

MVP

24-01-2019

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.