Replay and Topics

giri
giri Member, Administrator, Employee Posts: 116 admin
in PubSub+ Event Broker #1

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: 959 admin
    #2 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!

  • nram
    nram Member, Employee Posts: 80 Solace Employee
    #3 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

  • marc
    marc Member, Administrator, Moderator, Employee Posts: 959 admin
    #4 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!

  • giri
    giri Member, Administrator, Employee Posts: 116 admin
    #5

    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 ✓

    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.

Categories

This Month's Leaders

This Week's Leaders