In Adobe Experience Manager, replication agents are used to:
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.
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.
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 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.
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:
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.
@scr.component metatype="false" immediate="true"
@scr.service interface="org.osgi.service.event.EventHandler" @scr.property name="event.topics" valueRef="ReplicationAction.EVENT_TOPIC"
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
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.
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)
For more information, see http://helpx.adobe.com/experience-manager/kb/CQ53UnableToCreateJobQueueDueToMaxQueues.html.
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.
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.
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.
Sign in to your account