Distribution Queue blocked with AccessDeniedException

Description

Environment

  • Experience Manager
  • Experience Manage as a cloud service

Issues/Symptoms
When trying to replicate some Page content (or XF and other kind of resources) using the “Quick Publish”, “Manage Publication” or “Replicate”, the Distribution Queue on Author gets Blocked.
 
This can be observed by checking the publishDistribution Queue from the Distribution UI (AEM - Tools - Deployment - Distribution):

 
Selecting the Golden Publisher queue (entry in bold from the list), more details are given and in particular the involved PATH (there can be multiple elements here):

 
Looking into the Logs tab will show the following corresponding error:
2023/03/08 12:11:26:238 - INFO - Request accepted with distribution package PackageMessage(pubSlingId=a1133c97-6809-411e-a435-4eea0ecbe889, reqType=ADD, pkgId=dstrpck-1678277486031-63159f4b-c577-4079-8741-d41660597d20, pkgType=journal_filevault, pkgLength=6330, pubAgentName=publish, userId=replication-service, paths=/content/wknd/fr, deepPaths=) at offset=158705
2023/03/08 12:11:27:459 - WARN - Message: Failed attempt (0/infinite) to import the distribution package PackageMessage(pubSlingId=a1133c97-6809-411e-a435-4eea0ecbe889, reqType=ADD, pkgId=dstrpck-1678277486031-63159f4b-c577-4079-8741-d41660597d20, pkgType=journal_filevault, pkgLength=6330, pubAgentName=publish, userId=replication-service, paths=/content/wknd/fr, deepPaths=) at offset=158705 because of ‘javax.jcr.AccessDeniedException: OakAccess0000: Access denied’, the importer will retry later,
Stacktrace: org.apache.sling.distribution.common.DistributionException: javax.jcr.AccessDeniedException: OakAccess0000: Access denied
…
 
You need to Clear Queue (or remove that item) to unblock the queue.

Resolution

Despite the error being javax.jcr.AccessDeniedException, there is possibly no relation with the ACL / permissions for the distribution service users, though this should be considered if the following scenario does not apply to your case.

Diagnostics

The above error can occur in some situation, when the replicated content does have a specific configuration related to the special jcr:lockIsDeep property.

In order to confirm the diagnostic, you will have to inspect each of the mentioned path with any of the following tool that you can access/is applicable:

  1. CRX/DE for DEV instances
  2. the Repository Browser
  3. creating a content package in the Package Manager (this option is also part of the resolution)

Then you need to check the jcr:content node for each path found in the Distribution Queue UI, and verify if:

  • It does have a jcr:lockIsDeep=“(Boolean)true” property
  • It does not have a jcr:lockOwner="xxx" property
  • (it does not have a mix:lockable value in the jcr:mixinTypes)

If this is the case, then the issue is confirmed, since the jcr:lockIsDeep property should not be present alone. This property should always be set conjointly with the jcr:lockOwner when Locking a page.

It is not possible to only set the jcr:lockIsDeep property, even by using the JCR API, so the root cause explaining this situation is mostly by having installed a “corrupted” content package with that single property.

Resolution

To fix your content the only solution is to install a package in your Author that has the correct properties set on the corresponding node.

You can either create that package from another instance having the corresponding content, or if you only have this content on the impacted instance then you can follow those instructions:

  1. generate a package on broken instance for the faulty page
  2. download the package
  3. extract the .content.xml for the page/jcr:content
  4. remove manually the line with the jcr:lockIsDeep
  5. update your package with the new/fixed .content.xml
  6. re-upload and install the modified package

You can then check the page properties again, and test successfully the replication/distribution.

On this page