Playing Back a Replay Log

There are three Solace CLI commands that allow you to control message playback from an event broker.

For information about starting replay from a client, see Client Initiated Replay.

Initiating the Replay of Logged Messages Using start-replay

The start-replay command initiates a replay of logged messages from the replay log to the provided endpoint. 

solace> enable
solace# admin
solace(admin)# message-spool message-vpn <vpn-name>
solace(admin/message-spool)# queue <queue-name> | topic-endpoint <topic-endpoint-name>
solace(admin/message-spool/queue|topic-endpoint)# start-replay [replay-log <replay-log>] [from-date <from-date> | after-msg <replication-group-msg-id>]

Where:

  • <vpn-name>—The name of the Message VPN.
  • <queue-name>—The name of the queue.
  • <topic-endpoint-name>—The name of the topic endpoint.
  • <replay-log>—The name of the replay log.
  • <from-date>—The format YYYY-MM-DDThh:mm:ssTZD, where TZD is the time zone designator. For example, a from-date might look like: 2018-08-13T11:34:13-04:00.
    • If the from-date is earlier than the log's creation date, the replay will fail and the replay state of the endpoint will be failed.
    • If no from-date is given, replay will be initiated from the oldest available message.
  • <replication-group-msg-id>—The message after which to begin replay, identified by its replication group message ID. The provided string should be as given via a PubSub+ event broker management interface such as Solace CLI, PubSub+ Broker Manager, or SEMPv2. You can also obtain this value by converting the replication group message ID to a string using a PubSub+ Messaging API.

All messages stored on an endpoint are deleted prior to replay, and bound flows are unbound. PubSub+ Messaging APIs can handle this situation and automatically rebind to the endpoint. Also, upon receipt of a start-replay command, any replay already in progress on the endpoint will be canceled.

Initiating a replay to a partitioned queue, temporary topic endpoint, or temporary queue is not supported.

Messages that are replayed to a queue are not counted towards the queue's spool usage.

What happens to live messages received with a replaying endpoint destination?

Live messages received with a replaying endpoint as the destination won't be spooled to the endpoint, but instead will be put in the replay log. These messages will be replayed to the endpoint when the replay catches up to them. Endpoints that aren't undergoing replay, and have a matching topic subscription, will continue to receive messages.

What happens if there are no clients bound to a replaying endpoint?

If you start a replay on an endpoint that has no clients bound to it, at most 1,000 messages will be replayed to the endpoint. When clients bind, and as these messages are consumed, more messages will be replayed as replay resumes.

If no clients are bound to the endpoint, and fewer than 1,000 messages are to be replayed, the endpoint will immediately transition to the Pending Complete state and start attracting live messages.

What happens if a subscription changes during replay?

Replayed messages are based on the topic subscriptions at the start of replay. If you add, change, or remove subscriptions while replay is in progress, there is no change to the messages that are replayed.

What's the possible impact of trimming on replay?

When replaying from the beginning of the replay log, it might not be possible for a client to successfully complete a replay operation because the replay log is trimming messages faster than the client can consume them. For more information about trimming, see Trimming the Replay Log.

What's the impact of selectors?

We recommend that you avoid using egress selectors on queues because there are feature interactions that occur between selectors and message replay as follows:

  • If you replay to a queue that has one or more consumers and it uses egress selectors, you must ensure that the selector matches all replayed messages, otherwise message replay may not complete.
  • You can replay to a topic endpoint with an selector, but only the messages that match the topic endpoint subscription and the selector are replayed.

Deleting Replay Messages on the Provided Endpoint Using cancel-replay

The cancel-replay command deletes all replayed messages stored on the provided endpoint and disconnects bound clients. It also causes the endpoint to go into the Failed state, and causes any flows bound to the endpoint to be unbound.

solace> enable
solace# admin
solace(admin)# message-spool message-vpn <vpn-name>
solace(admin/message-spool)# queue <queue-name> | topic-endpoint <topic-endpoint-name>
solace(admin/message-spool/queue|topic-endpoint)# cancel-replay [force-complete]

Where:

  • <vpn-name>—The name of the Message VPN.
  • <queue-name>—The name of the queue.
  • <topic-endpoint-name>—The name of the topic endpoint.
  • force-complete—The paramater forces the replay to complete without waiting for bound clients to acknowledge the unsolicited unbind request and clears the Failed state.

Deleting Messages from Replay Log Using trim-logged-messages

The trim-logged-messages command deletes all messages from the replay log beginning with the oldest message in the log up to, but not including, <older-than-date>.

solace> enable
solace# admin
solace(admin)# message-spool message-vpn <vpn-name>
solace(admin/message-spool)# replay-log <replay-log-name>
solace(admin/message-spool/replay-log)# trim-logged-messages older-than-date <older-than-date>

Where:

  • <vpn-name>—The name of the Message VPN.
  • <replay-log-name>—The name of the message replay log.
  • <older-than-date>—The format YYYY-MM-DDThh:mm:ssTZD where TZD is the time zone designator. For example, an older-than-date might look like: 2018-08-13T11:34:13-04:00.