One of four JMeter remote engines is unreachable at startup. Which properties decide whether the run continues?
answer
- All three share one namespace prefix
- The default gives you no second chance
- One is a count, not a duration
- Even the permissive setting has a floor
basics
~10 sThree controller-side properties decide it: client.tries, client.retries_delay and client.continue_on_fail. Their defaults are one attempt, a five-second gap between attempts, and abort the run if any engine fails.
solid answer
~40 sThe controller reads `client.tries` (default `1`, meaning a single attempt, not one retry), `client.retries_delay` (default `5000` ms, applied only between attempts) and `client.continue_on_fail` (default `false`). If hosts remain unconfigured after the attempts and `continue_on_fail` is false, JMeter stops the engines it did configure and throws `Following remote engines could not be configured:[gen3]` — nothing runs. Set it to true and the run proceeds on the survivors, printing `Continuing without failed engines...`; but if *no* engine could be configured it still aborts, which JMeter's own tests pin down. All three keys live in the `client.` namespace and are read on the controller only, so writing them into a generator's `user.properties` has no effect. They also cover configuration alone: an engine that configures but fails to start is merely reported.
code
properties · 10 lines# user.properties on the CONTROLLER (the laptop), not on gen1..gen4
# three attempts instead of the default single one
client.tries=3
# pause between attempts, in ms (default 5000)
client.retries_delay=5000
# default false: any unconfigurable engine aborts the whole run
client.continue_on_fail=falsego deeper
Know that a distributed run stops by default when any listed engine cannot be reached, and that the message names the hosts that failed. The property names matter less than the behaviour at this level.
Explain the three keys and their defaults, and be precise that client.tries counts total attempts, so the default of 1 means the retry delay never applies.
Show that you read the controller console as three distinct stages — configured, started, ended — and that you would rather abort than publish a result from three of four generators.
Set the policy: whether a run is allowed to degrade to fewer engines, and what the report must say when it does. A silently short-handed run is worse than no run, because its numbers get compared to full-fleet ones.
## The three properties and their defaults All three are read by the **controller**, from the `client.` namespace, when it builds the distributed runner: | Property | Default | What it governs | |---|---|---| | `client.tries` | `1` | how many attempts are made to configure the engine list | | `client.retries_delay` | `5000` | milliseconds paused *between* attempts | | `client.continue_on_fail` | `false` | whether a run may proceed with fewer engines than asked for | `client.tries` counts **attempts, not retries**, so the default of `1` means one pass and no second chance; `client.retries_delay` never applies at the default because there is no gap to fill. Setting `client.tries=3` gives three passes with a five-second pause before the second and the third. ## What one attempt looks like For each host still outstanding the controller prints `Configuring remote engine: gen3`, looks the engine up, sends it the plan, and attaches any pushed properties. A host that succeeds is dropped from the outstanding list; a host that fails prints `Failed to configure gen3` and stays on it. When the list empties, the loop stops early — extra tries cost nothing when nothing is wrong. ## The decision at the end Once the attempts are exhausted and hosts remain, the controller takes one of two paths: 1. **`client.continue_on_fail=false`** — the default. It stops the engines it *did* configure and throws `Following remote engines could not be configured:[gen3]`. Nothing runs. This is the right default: three engines out of four means a quarter of the intended work is missing, and a run that quietly proceeds produces a number nobody can compare against anything. 2. **`client.continue_on_fail=true`** — it prints the same list, adds `Continuing without failed engines...`, and starts on the survivors. There is a third case that surprises people, and JMeter's own unit tests pin it down: with `continue_on_fail=true` but **no** engine configured at all, the run still aborts with the same exception. "Continue without the failures" cannot mean "continue with nothing", so a laptop pointed at four dead generators fails either way. ## What these properties do not cover The three properties govern the **configuration** phase only. Starting is a separate step with its own, quieter handling: - If an engine that configured cleanly then fails to start, the controller reports `The following remote engines have not started:[gen2]` on stderr and carries on with the rest — `client.continue_on_fail` has no say here. - If an engine dies mid-run, nothing retries it. The controller's end-of-test logic counts the engines that report their test has ended, so a generator that never reports leaves the controller waiting. A healthy four-engine run reads like this on the laptop: ```text Configuring remote engine: gen1 Configuring remote engine: gen2 Configuring remote engine: gen3 Configuring remote engine: gen4 Starting distributed test with remote engines: [gen1, gen2, gen3, gen4] @ ... Remote engines have been started:[gen1, gen2, gen3, gen4] ``` A run that lost `gen3` at configuration time and had `continue_on_fail` left at its default instead ends with `Stopping remote engines`, `Remote engines have been stopped` and the exception naming `[gen3]` — the already-configured engines are told to stop before the run gives up, so nothing is left half-armed. The practical rule: read the controller's console. `Configuring remote engine`, `Remote engines have been started:[...]` and `The following remote engines have not started:[...]` are three different lines from three different stages, and treating them all as "it worked" is how a three-engine run gets filed as a four-engine result. ## Where to set them On the laptop, not on the generators. A `client.tries=3` written into `gen1`'s `user.properties` does nothing at all, because no code on the server reads it. Either edit the controller's `user.properties` or pass the values on its command line for that run.
- With client.continue_on_fail=true, what happens when none of the four engines can be configured?The run still aborts with `Following remote engines could not be configured:[...]`. Continuing without the failures cannot mean continuing without any engine, so JMeter treats an empty engine set as fatal regardless of the flag. A shipped unit test asserts exactly this.
- gen2 configures cleanly but then fails to start. Does client.continue_on_fail govern that?No. That property is consulted only at the end of the configuration phase. A start failure is caught separately, reported as `The following remote engines have not started:[gen2]`, and the run proceeds on whichever engines did start — which is why the controller's console has to be read rather than skimmed.
- Why is client.tries=1 a sensible default rather than a stingy one?Because the usual causes of a configuration failure — the server process is not running, the port is wrong, the versions differ — do not fix themselves in five seconds. Retrying only helps when generators are still coming up, which is why raising it is worth doing for auto-provisioned hosts and pointless for static ones.
saying these in an interview costs you the question
- Reads client.tries as the number of retries after the first attempt.
- Sets the client.* properties on the generators instead of the controller.
- Thinks continue_on_fail=true lets a run start with zero engines.
- Believes the defaults let a run silently proceed with three engines out of four.
- Assumes these properties also cover an engine that dies mid-run.