Playing Back a Replay Log

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

To begin a playback, enter the following ADMIN commands.

solace> enable
solace# admin
solace(admin)# message-spool message-vpn <vpn-name>

:  For guidance in starting reply from a client refer to the section Client Initiated Replay.

start-replay

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

solace(admin/message-spool)# queue <queue-name> | topic-endpoint <topic-endpoint-name>
solace(admin/message-spool/queue|topic-endpoint)# start-replay [from-date <from-date>]

Where:

<queue-name> - is the name of the queue.

<topic-endpoint-name> - is the name of the topic endpoint.

<from-date> - is in 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.

All messages stored on the endpoint will be deleted prior to replay, and bound clients will be disconnected. Also, upon receipt of a start-replay command, any replay already in progress on the endpoint will be canceled.

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

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 the subscription on an endpoint changes?

if the subscription on an endpoint changes while a replay is in progress, the subscription change doesn't affect the replay. However, the subscription change may immediately affect which messages are logged.

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.

What's the impact of selectors?

Selectors can cause replays to never complete.

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 an unsolicited unbind request to be sent to disconnect any bound clients

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

Where:

<queue-name> - is the name of the queue.

<topic-endpoint-name> - is the name of the topic endpoint.

force-complete - forces the replay to complete without waiting for bound clients to acknowledge the unsolicited unbind request and clears the Failed state.

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(admin/message-spool)# replay-log <replay-log-name>
solace(admin/message-spool/replay-log)# trim-logged-messages older-than-date <older-than-date>

Where:

<replay-log-name> - is the name of the message replay log.

<from-date> - is in 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.