🎄 Happy Holidays! 🥳
Most of Solace is closed December 24–January 1 so our employees can spend time with their families. We will re-open Thursday, January 2, 2024. Please expect slower response times during this period and open a support ticket for anything needing immediate assistance.
Happy Holidays!
Please note: most of Solace is closed December 25–January 2, and will re-open Tuesday, January 3, 2023.
Replay and Topics
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?
Best Answers
-
Hey @giri,
As long as the messages are sent asPersistent
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 thepub/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 thepub/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!
0 -
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.
1
Answers
-
Hey @giri,
As long as the messages are sent asPersistent
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 thepub/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 thepub/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!
0 -
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.1 -
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.
1