Replaying a recording

Quick start

  1. Unzip LR4J-Record-*.zip (this creates a directory named lr4j).

  2. Replay the recording:

$LR4J_HOME/bin/lr4j_replay --input /path/to/recording.undo --port 9000

  1. Attach IntelliJ using the Undo Replay Recording run configuration (see Time travel debugging in IntelliJ).

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.

  • A JDK for any supported Java version. The JDK used for replay does not need to match the JDK used to make the recording.

  • The ability to copy the Undo for Java replay tools 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 Undo 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-Record-*.zip. This creates a directory named lr4j.

  • To replay a recording:

$LR4J_HOME/bin/lr4j_replay --input /path/to/recording.undo

$LR4J_HOME/bin/lr4j_replay --input /path/to/recording.undo --port PORT

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

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:

$LR4J_HOME/bin/lr4j_method_profile -k /path/to/keyfile -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:

$LR4J_HOME/bin/lr4j_method_profile -k /path/to/keyfile -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:

$LR4J_HOME/bin/lr4j_profile -k <keyfile> -i|--input <filename> -s|--samples <num_samples> [-l|--min <min_bbcount>] [-h|--max <max_bbcount>] [-v]
-k <keyfile>, --key <keyfile>

path to the license key file

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