Expand my Community achievements bar.

Error while building replication content com.day.cq.replication.AccessDeniedException: Replicaiton Agent

Avatar

Level 3

Hi All,

I am facing an issue while replicating pages, which has dispatcher flush rules configured as per ACS common configuration. Suddenly we started to face this issue after install SP3 and CFP1 on top of AEM 6.3.2.0.

We have an agent to flush certain resources (.json files) when a page under certain pattern is being replicated from author to publish. While doing so, we are facing the below error in logs:

flush agent.log:

ERROR - flush_resource_only : Unable to build content for agent 'flush_resource_only'.Agent User 'null' does not sufficient permission on '/bin/myproject/home'.

ERROR - flush_resource_only : Error while building replication content com.day.cq.replication.AccessDeniedException: Replicaiton Agent [flush_resource_only]- Agent user [null] doesn't have sufficient permission on [/bin/myproject/home]

Also while replicating, I am seeing the warning message in the siteadmin console at the right top as shown below:

1662225_pastedImage_2.png

Yes, as this is an issue related to ACS common compatibility, we have created a case in GIT as well. Also posting the problem statement here to get some view from AEM experts. This issue is as same as the following GIT post: DispatcherFlushRules break replication in 6.4.2 · Issue #1636 · Adobe-Consulting-Services/acs-aem-co...  but AEM versions are different.

PS: We have validated permission for root path in AEM as explained in acs-commons-dispatcher-flush-service system user dispatcher flush ACLs for jcr:removeNode · Issue #1... . But still the same issue.

Thanks in advance for any pointers.

Regards,

Dinesh.

8 Replies

Avatar

Level 10

Your error message suggests that there is a permission issue: Agent User 'null' does not sufficient permission.

Please double check those permissions.

Avatar

Level 10

I checked with the customer care team and they advice that you open a support ticket. They need to investigate this.

Avatar

Level 3

Hi Scott,

Thanks for your reply. I have raised an Adobe ticket as you suggested. But as this issue is related to ACS common + AEM 6331 handshake, daycare support team could not support on this. I have found the root cause for this issue. Just pointing the github ticket here: DispatcherFlushRules break replication in 6.3.3.1 · Issue #1668 · Adobe-Consulting-Services/acs-aem-...

No solution yet. Waiting for ACS common consulting team's view on this issue.

Regards,

Dinesh.

Avatar

Level 10

Probably, 'acs-commons-dispatcher-flush-service' doesn't have access to your '/bin/myproject/home' path which doesn't exist as it belongs to a servlet.

Could you change the servlet-path based approach to resourcetype/selector based approach or may be use a path that exists in the repo, provide proper ACLs and check if it works?

Avatar

Level 3

Hi Gaurav,

Thanks for your reply. We have few servlets which is being resolved by resource type. There is no issues with those flush rules. Here the issue is, we have 15 servlets which is is being resolved by /bin for some reasons. The same was working till AEM 6330. We have a ticket raised with daycare just to understand, why this path exist condition has been added for Replication.DELETE event. If there is some other intention behind this newly added condition, then we have to convert all the servlets to resolve by resource type.

Regards,

Dinesh.

Avatar

Level 2

Hi Dinesh,

Were you able to find a solution/work-around for this issue?

Avatar

Level 3

Hi W0lver!n3,

Day Care support team confirmed that this is a product bug in AEM 6.3.3.1 and also support executive said that they are tracking this issue with an internal ticket and will include a fix in AEM 6.3.3.3 (which is expected to be released by mid or end of March 2019).

Workaround could be: Convert all the servlets to be resolvable by resourcePath  instead of path or disabling caching for those servlet calls till the time, the above said hot fix will be available.

Regards,

Dinesh.