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 :
Please help me on this.
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.
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.
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 -
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?
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?
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-
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.
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.