Replay a directory

[stevenklassen8376]

A feature I would find useful would be to "replay" all the messages recorded in a directory at a speed comparable to their original. I could build this on top of rabtap by using a shell script or a Python script to examine the messages and the .json metadata files, but a built-in facility would be convenient.

It could look something like the following:

rabtap replay <directoryName> [--speed=1x]

where directoryName would be a directory containing previously recorded messages and their metadata. The speed parameter would specify how fast to replay the messages and would require that the timestamp had been added when the messages were originally sent. (Or the recording could be modified to automatically add a current timestamp as an option.) If no timestamps are present the replay would always be "as fast as possible".

The default speed of 1x would replay at real time as follows. The first message would be sent immediately and its timestamp would then be matched with the current timestamp. For all subsequent messages we would compute the duration between the timestamp and the first timestamp, add that duration to our starting timestamp, and pause until that time is reached. 2x, 3x, and so on (including 0.5x and other <1 numbers) would modify the duration appropriately. A value of "max" or perhaps "99x" or something similar would be used to indicate "as fast as possible", i.e. publish as soon as read.

The exchange and routing key for each message would by default be the same as when it was recorded, but could be overridden via the command line.

The idea of this feature is to allow a significant recording over time to be replayed in a manner similar to the original. This is useful for:

1. assisting developers to make changes for their components without having to have full end-to-end installations in place
2. allowing recordings to be used for automated testing
3. allowing recordings to be used for performance testing (i.e. can our new version keep up with the rates of the old version).

If this is deemed useful, our software team may be willing to perform the work.

[jandelgado]

Hi, thanks for the suggestions. Sounds like a valuable feature. I would suggest the CLI interface something like:

rabtap replay [--uri URI] [--exchange=EXCHANGE] [--routingkey=KEY] (--json=FILE | DIR )  [-kv]

• exchange and routingkey are optional and will be taken from the message metadata if not set.
• --json=FILE specifies a pre-recorded message file in JSON format
• DIR specifies a directory with pre-recorded messages and metadata
• --speed=SPEED specifies the speed (positive integer). If not set, replay messages in realtime, other wise apply inverse speed-factor to inter-message time intervals (as in your suggestion). Speed 0 runs replay at full speed without delays.
• The other options are as they are defined now

Would that be ok for you? To start I could extend the CLI code, so you could add the new command quickly (in a new branch).

[stevenklassen8376]

Sounds good. May take me a few weeks for this to get to the top of my priority list though. Also I have a couple of questions:

1. Does the --json=FILE option make sense? i.e. if it is just "playing" one file then isn't that already covered by the existing commands?
2. The realtime playback is dependant on the messages having the timestamp header set. If they are not set, then a realtime playback isn't possible, however one could still allow the full speed playback, or a set speed playback. That is, a set number of messages per second.

[jandelgado]

The JSON file format used by rabtap is actually a stream of JSON objects, each one representing a single message. It's like the directory with multiple metadata and message files, but everything is stored in a single JSON file (but the payload is base64 encoded). So, we should have this option included too.

Regarding the timestamp: I'll add a feature that adds a new metadata header when the message was received, something like `x-rabtap-received-timestamp', so we have a timestamp for every message.

Questions answered?

[stevenklassen8376]

I think so. I expect to start working on this sometime late next week.

[jandelgado]

Closed due to inactivity - will move it to backlog.

[stevenklassen8376]

Sorry about that. My need for it went away.

[PramodKumarYadav]

@jandelgado : I see that this is closed. I can still see a use for this in my tests. Normally, I use the messages and add the metadata to them after again base64 encoding them. This feature can help me refactor and simplify code. Also in general would be a good feature for rabtap. Any plans to pick it up in the recent future?

[stevenklassen8376]

I was the one who requested it, and who was going to implement it. But my need for it went away so the owner closed it due to lack of interest.

[PramodKumarYadav]

Oops, I thought, the owner was planning to implement it. Too bad :).

[jandelgado]

Hi there, If you want to implement the feature, we can re-open the issue. Anyhow, I was planning to implement a simple replay feature in the next weeks.

[jandelgado]

Implemented in Release 1.22 (See #39)

[PramodKumarYadav]

Thank you for implementing this feature! It enhances the functionality of rabtap by so much from a testing point of view. I can now refactor half of my code to use the benefit of this feature. To share how it improves the functionality, let me tell you what I need to do now vs, what this feature will bring to me.

1. I earlier had to create my own test raw json messages, which I then had to base64 encode and add to a dummy header to 'replay them'. All this code can be taken away now by giving the path of pre-recorded raw messages directory (so moving from raw(dir)-encoded json (dir) to only raw msgs (dir) in terms of test data storage).
2. For some weired reason, when I was piping my json messages to raptap publish, it was eating away the last closing bracket. And so to address that, I had to again do some patch work on it to make proper json. This feature, gives me proper json messages and take away the need to do that patch work.
3. For testing duplicates, I had to earlier store my messages in a separate repository since I publish both messages together, there was no guarantee that one will be published after another. With your current feature to add delays in publishing messages (we can be fairly confident) that they will be published in the same order as received. So again a great feature.
4. I am also hoping that the need to sort the messages in a certain order will go away with the introduced delays in publishing messages. So that is another plus.
5. All in all, all the ugly code I had to do to get this replay feature, can now be taken away from my framework with a much sleeker design - only due to this new feature.
   Thanks again and much appreciated you taking time to implement this feature!