Mastering JVM Sandbox Repeater: A Practical Guide to Traffic Recording and Playback

1. Introduction

Do you face problems such as cumbersome service refactoring, heavy regression testing effort, unreproducible online bugs, or difficult-to‑maintain automation cases? Existing traffic‑replay tools often have limitations like GET‑only support, lack of sub‑call mocking, and high environment/data dependencies, making both recording and replay painful.

What we need is a simple, safe, and reliable traffic recording and replay solution – jvm‑sandbox‑repeater.

2. jvm‑sandbox‑repeater Overview

jvm‑sandbox‑repeater is an open‑source traffic recording and replay tool released by Alibaba in July 2019. It provides recording/replay capabilities and a demo repeater‑console. Repository: https://github.com/alibaba/jvm-sandbox-repeater.

The framework builds on JVM‑Sandbox and offers:

Basic recording/replay protocol for quickly configuring middleware recording.

Open data reporting to custom back‑ends for monitoring, regression, and issue investigation.

It enables non‑intrusive API expansion, plugin development, and supports HTTP/Dubbo/Java traffic recording, sub‑call mocking, and more.

The recording process captures request, response, and sub‑calls, serializes them, and forwards them to repeater‑console for storage. During replay, the console selects recorded data, deserializes it, reconstructs the original request, and optionally mocks sub‑calls based on similarity matching.

3. Our Practical Implementation

While jvm‑sandbox‑repeater provides core recording/replay, a production‑grade solution requires a data center for collection, processing, storage, and search. The provided repeater‑console demo supports local or MySQL storage for single‑request scenarios. For batch recording, replay, and result viewing, we built a custom console and additional plugins.

Key extensions:

Implemented SOA, MongoDB, and Elasticsearch plugins.

Stored recording and replay results in Elasticsearch with extra fields for easier querying.

Added batch APIs in

RecordFacadeApi.java

for bulk fetch, replay, and result retrieval.

Deployed console independently; configuration fetched via

/facade/api/config/{app}/{env}

to reduce target server load.

Supported diff results stored in ES, enabling filtered queries for successful or failed replays.

4. Result Demonstration

After the enhancements, traffic replay becomes straightforward. The following steps illustrate a full cycle:

Start recording on the target server with

./sandbox.sh -p {PID} -P 12580

; logs confirm plugin loading.

View recorded results in batch via the console.

Perform batch replay, specifying the target server for each request.

Inspect batch replay results; diffs are stored alongside original and replay responses, allowing filtering by success/failure.

Monitor resource usage: recording consumes ~80 MB memory and occasional CPU spikes due to class instrumentation; network bandwidth is also used for console communication.

It is recommended to run replay offline because batch replay can be CPU‑intensive.

5. Pitfalls and Tips

Service requires at least 2 CPU cores; ThreadPoolExecutor fails on single‑core machines.

POST requests containing both params and body previously ignored params; the code now merges them.

HttpUtil only supports GET and POST; other methods need custom implementation similar to existing ones.

Mock matching uses 100% similarity; for time‑dependent or random parameters, fallback to highest similarity above a threshold.

Repeater does not compare HTTP status codes, only response bodies; non‑2xx responses trigger exceptions.

6. Conclusion

jvm‑sandbox‑repeater is a convenient, non‑intrusive traffic replay tool with hot‑plug capabilities, making it attractive for services with extensive legacy code. Its JVM‑level operation ensures good portability and extensibility. Future plans include adding more plugins (e.g., Kafka, Elasticsearch), platformizing configuration, recording, replay, and result management to further alleviate regression testing burdens.