Replay and Topics

Options
giri
giri Member, Administrator, Employee Posts: 109 admin

Based on my understanding, the replay feature records topic events that can be replayed at a later point in time. Would it record events on topics that does not have any subscriptions/subscribers?
If it does, the replay queue would become a catch-all, DLQ sort of thing. What is the expected behavior?

Tagged:

Best Answers

  • marc
    marc Member, Administrator, Moderator, Employee Posts: 923 admin
    #2 Answer ✓
    Options

    Hey @giri,
    As long as the messages are sent as Persistent I believe they will still end up in the replay log, even if there was not an endpoint subscribing. So yes, replay will essentially be a catch-all for your persistent messages. Then you can pick and choose what you want replayed to your app by tuning the endpoint subscription. So I can have messages being published to the pub/sub/plus topic today and tomorrow write an app that needs to process those messages. I can write my app and say "hey I really want to test this against the messages I was seeing yesterday" and to do this basically setup the queue, have it subscribe to the pub/sub/plus topic, initiate replay to put the messages onto the queue (no matter what messaging API I'm using: SMF, MQTT, JMS, AMQP, etc.) and start up my app to receive those messages. @Aaron created a cool replay video if you haven't seen it yet.

    Excited to hear what other ideas you have in mind!

  • nram
    nram Member, Employee Posts: 80 Solace Employee
    #3 Answer ✓
    Options

    I know this quite late in the thread's lifecycle ... Replay log also stores messages that are promoted persistent. For eg, a non-persistent message from a JMS publisher with default delivery mode Persistent in the connection factory is stored in the replay log, even if the destination is not subscribed on any endpoint.

Answers

  • marc
    marc Member, Administrator, Moderator, Employee Posts: 923 admin
    #4 Answer ✓
    Options

    Hey @giri,
    As long as the messages are sent as Persistent I believe they will still end up in the replay log, even if there was not an endpoint subscribing. So yes, replay will essentially be a catch-all for your persistent messages. Then you can pick and choose what you want replayed to your app by tuning the endpoint subscription. So I can have messages being published to the pub/sub/plus topic today and tomorrow write an app that needs to process those messages. I can write my app and say "hey I really want to test this against the messages I was seeing yesterday" and to do this basically setup the queue, have it subscribe to the pub/sub/plus topic, initiate replay to put the messages onto the queue (no matter what messaging API I'm using: SMF, MQTT, JMS, AMQP, etc.) and start up my app to receive those messages. @Aaron created a cool replay video if you haven't seen it yet.

    Excited to hear what other ideas you have in mind!

  • giri
    giri Member, Administrator, Employee Posts: 109 admin
    Options

    Thanks @marc - it is clear.
    Wanted to share a quick note on this topic - @TomF confirmed that the product team is working on a feature to select what topics to be logged for replay for optimal utilization of replay spool in the EMEA office hours with @Aaron YouTube session. This will empower the designers and developers for sure.

  • nram
    nram Member, Employee Posts: 80 Solace Employee
    #6 Answer ✓
    Options

    I know this quite late in the thread's lifecycle ... Replay log also stores messages that are promoted persistent. For eg, a non-persistent message from a JMS publisher with default delivery mode Persistent in the connection factory is stored in the replay log, even if the destination is not subscribed on any endpoint.