Replaying a recording¶
A Linux environment with access to the recording file. Usually it’s simplest if this is the same environment in which the application was recorded. However if the recording environment is transient - e.g. a container or on-demand cloud instance - it will be easier to replay in a more interactive environment such as a physical machine, a VM, WSL2, or a scratch container running a supported Linux distribution.
JDK that matches the major version of the JRE used to make the recording.
The ability to copy the LiveRecorder software into this environment.
(Optionally) a copy in this environment of the same build of jar files as supplied to Java at record time.
IntelliJ IDEA running in the same Linux environment as your application, or running on a separate Windows, macOS or Linux machine. Refer to Getting started if you don’t already have the Time Travel Debug for Java plugin installed and setup in IntelliJ.
- If the environment is a remote machine, or a VM or container running on your local machine:A port (default 9000) opened into the environment for IntelliJ to connect over.
The Time Travel Debug for Java IntelliJ plugin provides Run/Debug configurations for use with LiveRecorder for Java:
Open your project in IntelliJ if it’s not already open.
Under File › Project Structure… › SDKs check that the JDK version matches the version of the JRE used to make the recording.
From the Run menu choose Edit Configurations and press the + button at the top left of the Run/Debug Configurations dialog.
Add a Remote JVM Debug configuration
Specify the machine running your application as the Host. Use
localhostif you’re replaying on Linux, or in a VM or container running on your local machine.
Adjust the Port setting to match the port that you opened up into the remote environment above.
Ignore the recommended
Command line arguments for remote JVMas we are using our own replay tool which emulates a remote JDWP agent
In the replay environment:
Unzip the file
LR4J-Replay-*.zip. This creates a directory named
To replay a recording:
/path/to/lr4j/lr4j_replay -i /path/to/recording.undo -cp classpath or if not using the default port of 9000:
/path/to/lr4j/lr4j_replay -i /path/to/recording.undo -cp classpath -p PORT The ``classpath`` should point to the same build of jar files as supplied to Java at record time. This argument is optional, but if provided it can produce better display of variable contents in IntelliJ. This is because IntelliJ sometimes calls `toString` methods in the :term:`Bridge` that in turn invoke methods in classes that were not actually loaded during the recording. Try using if you notice that IntelliJ is sometimes displaying error strings instead of variable values.
Refer to Time travel debugging in IntelliJ for next steps.
Sometimes it can be the case that classfiles are present in a recording of which IntelliJ has no knowledge. In order to be able to step into these classes and set breakpoints, IntelliJ needs a jar containing the classfiles. You can extract the classes from the recording using the following command:
/path/to/lr4j/lr4j_extract -i /path/to/recording.undo -o /path/to/output.jar
output.jar will contain all the classfiles that were loaded during the recording
The following commands are run offline on a recording.
If you suspect that a particular method sometimes takes longer than expected to complete you can run a method profiling command on the recording to display a table showing both the bbcount and the elapsed wall-clock time for each call to that method. The command takes the form:
/path/to/lr4j/lr4j_method_profile -i /path/to/recording.undo -o /path/to/output.csv -m class.method [-v]
output.csv is csv version of the output. The
-v option produces verbose output including the
console log. The bbcount can then be entered into the log jump panel to go directly to
the start of that method in IntelliJ. For example:
/path/to/lr4j/lr4j_profile -i /path/to/recording.undo -o /path/to/output.csv -m org.springframework.samples.petclinic.customers.web.OwnerResource.findOwner ┌───────────────────────────────────────────────────────────────────────────┬────────────┬─────────────┬───────┬────────────┐ │location │start time │start bbcount│bbcount│milliseconds│ ├───────────────────────────────────────────────────────────────────────────┼────────────┼─────────────┼───────┼────────────┤ │org.springframework.samples.petclinic.customers.web.OwnerResource.findOwner│14:01:00.403│7524030 │77816 │109 │ ├───────────────────────────────────────────────────────────────────────────┼────────────┼─────────────┼───────┼────────────┤ │org.springframework.samples.petclinic.customers.web.OwnerResource.findOwner│14:02:09.777│32426403 │22216 │4 │ └───────────────────────────────────────────────────────────────────────────┴────────────┴─────────────┴───────┴────────────┘
You can generate a profile showing where the cpu time is spent in a recording by running the following command:
/path/to/lr4j/lr4j_profile [-i|--input <filename>] [-s|--samples <num_samples>] [-l|--min <min_bbcount>] [-h|--max <max_bbcount>]
- -i <filename>, --input <filename>¶
the name of the recording file
- -s <num_samples>, --samples <num_samples>¶
the number of samples to take
- -h <max_bbcount>, --max <max_bbcount>¶
the maximum bbcount to start sampling (default the end of the recording)
The command works by dividing the bbcount range (default the whole recording) by the given number of samples and obtains the Java stack at that point in the recording. It then outputs a tree summarising the most commonly called methods. There is also a -v option which produces verbose output containing every stack sampled together with its bbcount. The bbcount could then be entered in the Log Jump panel to investigate further. Note that the recording only contains cpu activity so if for instance a large part of the recorded program was waiting on I/O those stacks would not show.
There are many other types of post-failure analysis that can be run on a recording. Contact Undo support for more details.