Replay service¶
The replay service is a solution that allows the seamless replay of Undo recordings regardless of their hardware requirements (architecture, CPU features, memory requirements, etc.).
The replay service manages a pool of machines for replaying recordings. When loading a recording that cannot be replayed locally, UDB contacts the replay service to see if the pool has a machine with the necessary capabilities; if so, the recording is automatically copied to the remote machine and replayed there.
The server-side component of the replay service uses Docker Swarm to manage the replay tasks, and can be deployed on premises or to a cloud environment.
Note
We are partnering with key customers to develop other services — such as services for source and symbol management, Undo configuration management, and license management. Contact Undo Support if you want to get involved.
Installing the replay service¶
The replay service is distributed separately from UDB (via a Docker repository), and requires one or more appropriate machines to run the service and replay recordings. To install the replay service, please get in touch with us at Undo Support.
Using the replay service¶
A typical use case is replaying a recording generated on a different machine, for instance, generated on a server or in continuous-integration. If a replay service is configured, then UDB automatically uses it to replay recordings that it cannot replay locally:
not running> uload recording_with_incompatible_features.undo
This recording cannot be replayed locally, so it will be loaded on a replay
service machine.
Setting up a replay machine...
Uploading recording...
Starting replay...
Remote debugging using 10.1.3.250:30157
[...]
After the uload command completes, the recording can be debugged as usual:
start 1> break main
Breakpoint 1 at 0x55b427b51141: file hello-world.c, line 9.
start 1> continue
Continuing.
Breakpoint 1, main () at hello-world.c:9
9 for (int i = 0; i < 3; i++)
UDB uses the replay service automatically only in the following cases:
Architecture mismatch. For instance, when replaying an ARM64 recording on an Intel or AMD x86-64 machine.
CPU feature mismatch. For instance, when replaying a recording made on a machine with AVX-512 support on a machine without this feature.
Incompatible virtual address sizes. For instance, when replaying a recording made on a machine which supports Intel 5-level paging on a machine which doesn’t support this feature.
In other cases, it’s possible to force UDB to use the replay service by passing the
-remote
option to the uload command.
Similarly, it’s possible to request UDB to always attempt the local on the current machine by
specifying the -local
option.