What does JMeter's mode property select for a distributed run, and what is its default?
answer
- One property, read in one place only
- It names a class, not a file format
- Nine built-ins, and one is the default
- Four of the nine start with Stripped
basics
~10 sJMeter's mode property names the SampleSender each engine uses to return results to the controller. It is read on the controller only, and defaults to StrippedBatch: batched sends with response bodies removed.
solid answer
~40 sIn Apache JMeter 6.0.0 the `mode` property is read by `SampleSenderFactory` when the controller converts the test tree for remote execution, and it chooses the `SampleSender` implementation that will be serialised to every engine over RMI. Nine values are built in — `Standard`, `Batch`, `Statistical`, `Stripped`, `StrippedBatch`, `Asynch`, `StrippedAsynch`, `DiskStore`, `StrippedDiskStore` — and each `Stripped*` value is simply a `DataStrippingSampleSender` decorating the matching plain sender. The default is `StrippedBatch`, so out of the box results come back in batches with response data removed. Anything the factory does not recognise is treated as a fully qualified class name and loaded reflectively, which means a typo throws `IllegalArgumentException` at start-up rather than falling back to a default. Because the property is resolved on the controller, setting it in an engine's `jmeter.properties` has no effect at all.
go deeper
Recall that mode is a jmeter.properties key controlling how remote results come back, and that its default is StrippedBatch. Knowing the default explains most surprises in a first distributed run.
Explain the mechanism: the controller builds a SampleSender from mode and ships it to each engine, where it runs. List the built-in values and say which of them are stripping decorators over another sender.
Show that you pick a value from a measured constraint rather than habit, and that you know an unrecognised value is loaded as a class name and aborts the run when it cannot be constructed.
Own the default across the fleet, including whether a custom SampleSender is worth maintaining. Weigh the operational cost of a bespoke class on every node against the modes that already ship.
## What `mode` actually selects When you start a distributed run, `ClientJMeterEngine` traverses the test tree with `ConvertListeners` and replaces every `Remoteable` listener with a `RemoteListenerWrapper`. That wrapper's constructor calls `SampleSenderFactory.getInstance(listener)`, which reads `mode` and returns a `SampleSender`. The wrapper — sender and all — is then serialised to each engine over RMI, where `readResolve()` acts as the sender's `testStarted()`. Every sample an engine produces goes through that object on its way home. Two consequences follow immediately, and both are commonly missed: - **`mode` is read on the controller.** Putting `mode=Standard` in an engine's `jmeter.properties` changes nothing; the choice was already made and shipped. - **The sender runs on the engine.** Queues, batches and temp files created by a mode live on the engine, while the receiving pressure lands on the controller. ## The nine built-in values | `mode` | Implementation | Behaviour | |---|---|---| | `Standard` | `StandardSampleSender` | one RMI call per sample, synchronous | | `Batch` | `BatchSampleSender` | accumulate, flush on a count or time threshold | | `Statistical` | `StatisticalSampleSender` | one aggregate per sample label and thread group | | `Stripped` | `DataStrippingSampleSender` | `Standard`, minus response data | | `StrippedBatch` *(default)* | stripping wrapper over `BatchSampleSender` | `Batch`, minus response data | | `Asynch` | `AsynchSampleSender` | engine-side queue drained by a worker thread | | `StrippedAsynch` | stripping wrapper over `AsynchSampleSender` | `Asynch`, minus response data | | `DiskStore` | `DiskStoreSampleSender` | serialise to a temp file, replay at test end | | `StrippedDiskStore` | stripping wrapper over `DiskStoreSampleSender` | `DiskStore`, minus response data | Matching is case-insensitive: `stripped_batch` will not match, but `strippedbatch` will. ## Anything else is a class name The final branch of the factory does `Class.forName(type)` and looks for a **public** constructor taking a single `RemoteSampleListener`. That is the documented extension point: write your own sender, put it on the classpath of both nodes, and set `mode=com.example.MySampleSender`. When the lookup fails, the factory logs an error and throws `IllegalArgumentException: Unable to create a sample sender from mode or class:'...'` — so a misspelled mode aborts the run at start-up instead of silently reverting to the default. That is a feature worth knowing about, because it turns a typo into a loud failure. One live trap: the 6.0.0 user manual's remote-testing page still lists a `Hold` mode, but `HoldSampleSender` was removed from the factory in JMeter 4.0. `mode=Hold` now falls into the class-name branch and fails. **When the manual and the shipped factory disagree, the factory wins.** ## Picking a value - **`StrippedBatch`** — leave it alone unless you have a reason. It is the default because it is the cheapest sensible option for a large run. - **`Batch` / `Standard`** — when you need response bodies on the controller. - **`Statistical`** — when the controller cannot keep up with the number of results, not just their size. It replaces individual results with aggregates. - **`Asynch` / `StrippedAsynch`** — when you want the sampler thread not to wait on the network. - **`DiskStore` / `StrippedDiskStore`** — when engine memory is the constraint and you can afford every sample arriving at the end of the run instead of during it. Whether the statistic you intend to report survives a given choice is a performance-testing fundamentals question, not a JMeter configuration one; here the point is simply which object gets serialised to the engines and what it is allowed to drop.
- You set mode on your engines and nothing changed. Why?`mode` is resolved on the controller. `ConvertListeners` builds the `RemoteListenerWrapper` there, and its constructor calls `SampleSenderFactory.getInstance`, which reads the property from the controller's `jmeter.properties`. The chosen sender is then serialised to the engines, so their own value is never consulted.
- What happens if you misspell the mode value?The factory treats any unrecognised value as a class name, calls `Class.forName`, fails, and throws `IllegalArgumentException` naming the value. The run aborts at start-up rather than quietly using the default, which makes typos loud instead of silent.
- How would you plug in your own sample sender?Implement `SampleSender` (usually by extending `AbstractSampleSender`) with a public constructor taking a single `RemoteSampleListener`, put the class on the classpath of both controller and engines, and set `mode` to its fully qualified name on the controller.
saying these in an interview costs you the question
- Says mode is a listener setting inside the .jmx plan
- Sets mode on the engines and expects it to apply
- Thinks mode chooses the JTL file format
- Claims an unknown mode value falls back to the default
- Believes Stripped and StrippedBatch differ only in name