Adobe Experience Manager Replication FAQs

In Adobe Experience Manager, replication agents are used to:

• Publish (activate) content from an author to a publish environment.
• Explicitly flush content from the Dispatcher cache.
• Return user input (for example, form input) from the publish environment to the author environment (under control of the author environment).

This article covers frequency asked questions that relate to using AEM replication functionality. 

Instead of having all sibling pages on a single level, create sublevels and distribute the pages accordingly. Having around 100 pages is acceptable in a single level. For more information, see http://helpx.adobe.com/experience-manager/kb/ReplicationSiblingReordering.html.

Replication failure after IP renewal 

Restart the instance or reconfigure the replication agent to use the IP instead of host name. For more information, see http://helpx.adobe.com/experience-manager/kb/ReplicationFailureAfterNewIP.html.

Limit access to replication agents 

You can control this setting using user/group page permissions under etc/Replication (that is, /etc/replication node). For more information, see http://helpx.adobe.com/experience-manager/kb/LimitAccessToReplicationAgents.html. 

Page permissions are not replicated on user activation 

Page permissions are not replicated because they are stored under the nodes to which access is granted, not with the user.

In general, page permissions should not be replicated from the author to publish and are not by default. This is because access rights should be different in those two environments. Therefore it is recommended to configure ACLs on publish separately from author. For more information, see http://helpx.adobe.com/experience-manager/kb/PagePermissionsNotReplicatedWithUser.html.

Use reverse replication

Out-of-the box, only cq:Page nodes are reverse replicated. For any other node, it's necessary to use the two last methods, as a project-specific implementation.

There are three possibilities:

1. Use the SlingPostServlet (that is, do not create any custom post servlets or POST.jsp to handle the incoming requests) so that it implicitly triggers a related PageEvent. Then set a property name "cq:distribute" and set its value to "true" on the nodes you want to reverse replicate. To implement this solution, it's unnecessary to write any code. You can use the Form component to set all the necessary hidden fields.
2. Use your own code that accesses the repository, modify the properties "cq:lastModified," "cq:lastModifiedBy" and "cq:distribute." Posted data can be controlled, internal code writes the data. To implement this solution, it's necessary to write the code for your project.
3. Use your own code that calls the replicate method from Replicator service with options to use distribution mode. Replication is controlled from your code. To implement this solution, write the code specific for your project.
   

Activate to a specific replication agent

You can create a ReplicationOptions  object with an AgentFilter:

ReplicationOptions opts = new ReplicationOptions();
opts.setFilter(new AgentFilter(){
public boolean isIncluded(final Agent agent) {
return "expectedAgentId".equals(agent.getId());
}
});
then use the Replicator"s replicate method:

/**
* Triggers a new replication with supplied options.
*
* @param session user session
* @param type The type of replication
* @param path The path specified the content to be replicated
* @param options Additional replication options
* @throws ReplicationException if an error occurs
*/
void replicate(Session session, ReplicationActionType type, String path,
ReplicationOptions options)

For more information, see http://helpx.adobe.com/experience-manager/kb/CQ5ReplicateToSpecificAgents.html.

Implement a Replication Event Listener 

1. Create a class that implements EventHandler interfaces. 
2. Add the following SCR annotations:
   @scr.component metatype="false" immediate="true"
@scr.service interface="org.osgi.service.event.EventHandler" @scr.property name="event.topics" valueRef="ReplicationAction.EVENT_TOPIC"
3. Implement public void handleEvent(Event event) method.

Replication queue issues 

The CQ5 content replication appears to be blocked

Editors can create content, but the activated pages are not updated on the CQ5 publish instance.

Make sure that each replication agent is enabled and configured correctly

1. Go to the list of replication agents (/etc/replication/agents.author.html). 
2. For each replication agent, do the following:

• Make sure that the agent is enabled. 
• Verify the connectivity with the publish instance by clicking Test Connection. If it fails, make sure that on TCP network level, the server hosting the CQ author instance can connect to the port of the publish instance.
• Open the replication log via the "View Log" link and check when the last replication attempt was successful.
• Note the first payload path in the replication queue. Then try to clear the first element of the replication queue. Then, verify whether the replication resumes (starting with CQ5.4). Once it resumes, activate the first payload noted in the queue again.
• Check with the CRX Content Explorer, and make sure that there is no /bin/receive node on the publish instance. Otherwise, delete it.
• Check with the CRX Content Explorer, and make sure that there is no /bin/replicate node on the author instance. Otherwise, delete it. 
• If the logs show no replication attempt for a few minutes, restart the replication bundle in the Felix console. If there's still no replication attempt in the replication logs, then restart the Apache Sling Event Support bundle:
  (http://<host>:<port>/system/console/bundles/org.apache.sling.event)

Replication Privileges missing after upgrade to CQ 5.5 

The replication privileges are lost because of new property that was introduced in CQ 5.5 called crx:replicate.

You can locate an attachment that is a package with a script that fixes the problem. Simply run it BEFORE the upgrade to CQ5.5. For information, see http://helpx.adobe.com/experience-manager/kb/replication-privileges-missing-after-upgrade-to-cq-5-5.html.

CQ5.3: Replication agents fail due to maximum job queue limit

The cause of this issue is the org.apache.sling.event.impl.JobEventHandler has a default limit of 10 on the number of job queues that the system can create.

Resolution
Increase the maximum number of Job queues as needed (the number of queues should be higher than the number of configured replication agents + number of workflow models)

1. Log into the Felix Console (http://host:port/system/console/configMgr). 
2. Go to the Configuration tab in Felix console. 
3. Select "Apache Sling Job Event Handler (org.apache.sling.event.impl.JobEventHandler)" from the drop-down list. 
4. Change "Max Job Queues" value. 
5. Click save.

For more information, see http://helpx.adobe.com/experience-manager/kb/CQ53UnableToCreateJobQueueDueToMaxQueues.html.

ACL replication

It's not possible to replicate ACLs anymore (that is, from the author instance to the publish instance). This behavior is by design.

The ACLs in CQ5 are content-centric, and not user-centric as in CQ4. Usually you have different access rights on publish and author from a content perspective. So it makes no sense to replicate the content-centric ACLs anymore.

With a CUG (closed user group), Adobe is working on an out-of-the-box solution. In the pageprops of a page, it allows you to protect this page (and all subpages) by a specific CUG. That way, only users that are members of a specific group have access. The ACL on the publish is set on the publish itself automatically if the page is activated. For more information, see http://helpx.adobe.com/experience-manager/kb/ACLReplication.html.

Content growth due to reverse replication 

The repository grows fast (several MB per minute), and logs show an error about reverse replication.
For example, "WARN [Reverse Replication Processor] com.day.cq.replication.Agent.publish_reverse Reverse replication not implemented for action: TEST. Remote outbox path: /var/replication/outbox."

On the publish instance, find and delete the item from the publish box manually.

To avoid this issue in the future, either upgrade to CQ 5.6 or don't use the Test Connection button on the reverse replication agent.

Check with Adobe Support for an existing hot fix if you're having similar issues with reverse replication. (Also see the recommended list of hot fixes for CQ 5.4.)

Form more information, see http://helpx.adobe.com/experience-manager/kb/content-grow-due-reverse-replication.html. 

Replication agent uses anonymous user as transport user 

You have a replicating agent with the correct ACL rights. However, when you try to replicate with this agent, you see the following in your replication logs:

13.06.2007 12:34:36 *INFO * author: << Date: Wed, 13 Jun 2007 10:34:36 GMT 13.06.2007 12:34:36 *INFO * author: << error: java.security.AccessControlException: User 'anonymous' not allowed rights '---c-' on handle /content/playground/en 13.06.2007 12:34:36 *INFO * author: Message sent. 13.06.2007 12:34:36 *INFO * author: ---------------------------
To address this issue, deny read access of /system/replication/content for anonymous user in your target instance. For more information, see http://helpx.adobe.com/experience-manager/kb/ReplicationAgentUsingAnonUser.html.