Try PubSub+

Replay and Topics

girigiri Member, Employee Posts: 17 Solace Employee

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

  • marcmarc Member, Administrator, Moderator, Employee Posts: 422 admin
    #2 Accepted Answer

    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!

  • nramnram Member, Employee Posts: 48 Solace Employee
    #3 Accepted Answer

    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

  • marcmarc Member, Administrator, Moderator, Employee Posts: 422 admin
    #4 Accepted Answer

    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!

  • girigiri Member, Employee Posts: 17 Solace Employee

    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.

  • nramnram Member, Employee Posts: 48 Solace Employee
    #6 Accepted Answer

    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.

Sign In or Register to comment.