Replaying from the Replay Log

This section describes how a client application should handle an event broker initiated message replay, and how a client application may initiate a message replay entirely on its own behalf.

If you're not familiar with Message Replay, take a look at Message Replay Overview for a high-level introduction, and for detailed information on how to configure and use the feature on the event broker have a look at Message Replay Configuration.

Also, there's a Solace Java API tutorial that shows you how a client can initiate and process a replay.

Event Broker Initiated Replay

Client Initiated Replay

A client can initiate message replay for a variety of reasons including that it may be able to detect that it needs to replay messages from the replay log, or there may be a start-up condition in the client that requires that messages are replayed from a certain point-in-time.

Message replay may be initiated by a client whenever it binds to a queue or topic endpoint. You may want to consult your API's reference documentation for specific details on how to bind to a queue or topic endpoint. When creating a guaranteed message receiver, either flow or consumer, the application may specify a flow property, REPLAY_START_LOCATION, to indicate the point-in-time to begin a message replay. Its value may be either BEGINNING, to specify that the message replay should start from the beginning of the replay log, or a timestamp, in one of the following the formats, to specify that the message replay should begin from a particular point-in-time (refer to RFC 3339 if you need more information on the timestamp's format):

  • For UTC time: YYYY-MM-DDTHH:MM:SSZ
  • For HH:MM offset from UTC: YYYY-MM-DDTHH:MM:SS[+-]HH:MM

You should keep in mind that replay attempts from a timestamp earlier than when the replay log was created will fail.

:  The C API can specify the start time using either the RFC 3339 format shown above or UNIX time formatting.

When the flow is successfully bound, it will receive all messages from the replay log starting from REPLAY_START_LOCATION.

Restrictions on client initiated replays

  • Not supported on non-exclusive endpoints.
  • Can't be initiated from a non-active flow.
  • Can't be initiated on a browser flow.
  • Can't be done using the JMS API.

If your application wishes to replay messages for a certain topic to a queue

When connecting to a topic-endpoint, the topic to be replayed from the replay log is set in the flow properties when the flow is created. If connecting to a queue, the messages published to the queue, that match subscriptions that exist on the queue prior to creating a flow, will be replayed. If the application wishes to replay messages for a certain topic to a queue, it must be sure to add a subscription to the queue before connecting the flow.

Replay failure

If a message replay fails, the event broker sends an unsolicited unbind, and the API's flow event handler will receive a flow_down event. Refer to your API's documentation for the different subcodes that could be received.