Replication
Purpose: How content moves author → publish: agents, queues, and the developer-visible behaviours.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| All engineers | Publish problems are replication problems half the time |
Mechanics
Each publish instance has a replication agent on author (/etc/replication/agents.author). Activating a page serialises the content and queues it per agent; delivery is HTTP to the publisher's receiver servlet. A separate flush agent (usually on publish) tells the dispatcher to invalidate.
Activate page ──▶ agent queue (publish1) ──▶ publish1 repo ──▶ flush agent ──▶ dispatcher1 .stat
└──▶ agent queue (publish2) ──▶ publish2 repo ──▶ flush agent ──▶ dispatcher2 .statProperties of the system
| Property | Consequence for you |
|---|---|
| Per-agent queues, independent | One publisher can lag/fail while others are current |
| Ordered within a queue | Bulk activations process serially — tree activations take time |
| At-least-once delivery, retry on failure | A blocked queue halts ALL content updates to that publisher |
| Content only (plus users/config if configured) | Code never replicates — deploys handle code |
What activates what
- Activating a page replicates the page; referenced assets/XF/CFs are offered (based on references) — authors can deselect; missing references on publish = broken pages.
- Deleting on author + activate = deactivation/removal on publish.
- On/off times are evaluated on publish at request time — content replicates ahead, shows when "on".
Developer/debug notes
- Queue UI: author → Tools/Deployment/Replication (or
/etc/replication.html) — blocked queues show retries and the failing payload; see Replication queue blocked. - Test connection button on the agent verifies transport/credentials.
- Never point replication agents at dispatchers/CDN — they target publish receivers directly.
- Reverse replication (publish → author) exists for user-generated content but is rare and discouraged in new designs — prefer APIs.