Replay and Topics

giri

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?

marc

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

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.

marc

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

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

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.