Replaying a recording

Requirements

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.

Replaying

The Time Travel Debug for Java IntelliJ plugin provides Run/Debug configurations for use with LiveRecorder for Java:

Windows or macOS

  • 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 localhost if 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 JVM as 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 lr4j.

  • 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.

Linux

As an alternative to the above, on Linux there is a Run Configuration which can be used to launch the replay session directly.

  • First, set Settings › Tools › LiveRecorder › Replay tool directory to the location of the unzipped LR4J-Replay-*.zip directory.

  • From the Run menu, choose Edit Configurations and press the + button at the top left of the Run/Debug Configurations dialog.

  • Add a Undo Replay Recording configuration.

  • Set Recording file to the name of the recording you wish to replay.

Refer to Time travel debugging in IntelliJ for next steps.

Extracting classfiles

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

The resulting output.jar will contain all the classfiles that were loaded during the recording

Profiling commands

The following commands are run offline on a recording.

Method profile

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]

where 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           │
└───────────────────────────────────────────────────────────────────────────┴────────────┴─────────────┴───────┴────────────┘

Recording profile

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

-l <min_bbcount>, --min <min_bbcount>

the minimum bbcount to start sampling (default 1)

-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.