Replication Queue Full

If the standby site is down or unreachable for an extended amount of time, the replication queue (#MSGVPN_REPLICATION_DATA_QUEUE) can eventually become full. It is assumed that replication is a high-priority service, so the replication queue size should be set to a large value. A system administrator can adjust the quota of a replication queue. Like all queues, the replication queue has threshold event logs as it fills up, which warns you that the queue may become full and action should be taken.

By default, if the replication queue becomes full, publishing to replicated topics or using replicated transactions is rejected. No new replicated messages or transactions can be processed. To restore non-replicated service, the administrator has the option of disabling this behavior (by disabling the reject-msg-to-sender-on-discard feature on the replication queue). With this configuration, messages and transactions are not replicated, but local service can be provided. If connectivity is restored and the replication queue is drained, replication will start again. At this point, the administrator should re-enable reject-msg-to-sender-on-discard on the replication queue.

Pruning the Replication Queue

When the standby site is down and the active site is storing messages and transactions in the replication queue, there is an optimization to help prevent the replication queue from becoming full. Replicated messages that are waiting to be sent to the standby site do not need to be sent if the message has subsequently been consumed on the active site. Since the message is no longer present on the active site, there is no need to send it to the standby site for replication purposes. In this case, those messages are removed, or pruned, from the replication queue, helping to prevent it from becoming full.