7.3 Replication Agents & Sling Content Distribution

7.3 Replication Agents & Sling Content Distribution

Quick Answer: AEM 6.5 commonly publishes through forward replication agents that send activation content to configured Publish receivers, followed by Dispatcher cache invalidation. AEM as a Cloud Service uses Sling Content Distribution and Adobe Pipeline so the Author service does not maintain fixed network targets for changing Publish instances.

Classic Replication in AEM 6.5

A forward replication agent on Author has a transport endpoint, credentials, serialization settings, triggers, retry behavior, and a queue. When an author activates content, AEM serializes the selected repository change and sends it to the Publish replication receiver. A successful receiver response removes the entry from the queue.

Key agent roles include:

• Default or forward agent: Transfers activated content from Author to Publish.
• Dispatcher Flush agent: Sends invalidation requests so stale cached responses are not served after publication. It does not carry the page content itself.
• Reverse replication agent: A legacy mechanism in which Author polls a Publish outbox for selected user-generated content. It is not the Cloud Service publication model.

Every Publish target needs an appropriate agent or supported shared configuration. Fixed endpoints and local queues fit static AEM 6.5 topologies but do not fit an environment whose runtime instances can change dynamically.

Ordered Queue Diagnosis

A classic replication queue processes entries in order. If the head entry repeatedly fails, later activations wait. Do not begin by clearing the queue; that loses pending publication work and can leave Publish inconsistent with Author.

Use this sequence:

1. Open the affected agent and inspect the first active or blocked item.
2. Test the agent connection and confirm the configured receiver URL.
3. Check Author error.log and replication-related logs for the transport response.
4. Check the target Publish logs for authentication, receiver, import, repository, or disk failures.
5. Correct the connection, credential, certificate, endpoint, or target-side error.
6. Retry the entry and verify the queue drains in order.
7. Re-publish only the content that was lost if an entry had to be removed under an approved recovery plan.

A missing template or component can make a published page render incorrectly, but it does not normally block the transport queue as a dependency-resolution gate. Separate publication transport success from render-time completeness.

Dispatcher Cache Invalidation

Publishing content and invalidating cached output are two connected but distinct operations. The forward agent updates Publish. The flush mechanism touches relevant Dispatcher invalidation state. A queue can be healthy while a misconfigured Flush agent leaves stale HTML, or the cache can invalidate even though a later Publish rendering error produces bad output.

For a stale-page incident, verify:

• publication status on Author;
• content presence and replication metadata on Publish;
• Flush agent success;
• Dispatcher .stat behavior and cache logs;
• CDN caching and Cache-Control behavior.

Cloud Service Distribution

AEM as a Cloud Service removes customer configuration of classic replication agents for its managed Author-to-Publish path. Adobe documents Sling Content Distribution together with Adobe Pipeline as the publication mechanism.

The architectural result is decoupling:

• Author publishes into the managed distribution path.
• The Publish service receives and applies distributed content without the customer configuring a fixed endpoint for each runtime node.
• Adobe can replace or scale service instances without requiring an Author agent rewrite.
• Publication remains asynchronous, so success should be verified through status and logs rather than assumed from the author's click alone.

Do not over-specify private implementation details. Public documentation does not require an exam candidate to memorize a per-pod subscription algorithm, a customer-visible central queue, or a particular FileVault package format for every distribution event.

Binaries and Published Metadata

Assets combine repository metadata with binary data. Cloud Service binary storage and distribution optimizations can avoid copying identical binary bytes through every application node. The developer-facing rule is to publish the asset and its required metadata through supported AEM workflows; do not write integration code that assumes every Publish instance has a permanent local binary file path.

Reverse Flow

Classic reverse replication polled a Publish outbox for selected content such as legacy user-generated data. Modern Cloud Service designs should use supported external persistence, APIs, or event integrations for user-generated data. Adobe explicitly states that reverse replication from Publish to Author is not supported in AEM as a Cloud Service.

Comparison

For exam questions, identify whether the scenario describes a visible classic agent queue or the managed Cloud Service publication path. The corrective action follows that boundary.