In a JMeter distributed run, which JVMs does the -G flag set properties in?

## The two forms of the flag `-G` (`--globalproperty`) may be repeated, and it accepts two shapes: ```bash # one key at a time jmeter -n -t plan.jmx -R gen1,gen2,gen3,gen4 -Gdataset=eu -Gbaseurl=https://staging.internal # a whole file, loaded and sent as a unit jmeter -n -t plan.jmx -R gen1,gen2,gen3,gen4 -Gper-run.properties ``` JMeter distinguishes the two by whether it sees a `=`. With `key=value` it stores that pair; with a bare argument it treats the argument as a filename, and if the file is readable it loads every pair in it. If the file is *not* readable JMeter says nothing — there is no error and no warning, and the run proceeds with an empty set. That silence is the trap worth remembering. ## Where the values end up Follow one run from the laptop to `gen1`–`gen4`: 1. Argument parsing accumulates every `-G` pair into one collection of properties on the controller. 2. The distributed runner attaches that collection to each engine as it is configured. 3. Immediately after sending the plan, and before telling the engine to run, the controller makes a separate call that carries the properties to the server. 4. The server merges them into **its own** JMeter properties, the same map that `bin/jmeter.properties` and `user.properties` fill on that host. The consequence people get wrong: **the controller's own properties are untouched.** `-G` is a push to the engines, not a local assignment that happens to be forwarded. On a purely local `jmeter -n -t plan.jmx` with no `-r` or `-R`, JMeter still collects the `-G` values and then has nowhere to send them, so they have no effect at all. The ordering is fixed and occasionally matters: the plan is configured on the engine **first**, the properties are sent **second**, and only then is the engine told to run. So a value pushed with `-G` is in place before any thread starts, but it is not available while the tree is being configured. A run with no `-G` at all still makes the same call with an empty set. When a key you push also exists in the generator's own `bin/jmeter.properties` or `user.properties`, the pushed value wins: the server merges the incoming pairs into the very same property map those files filled, so the later write replaces the earlier one. | | Set on the controller | Set on each server | |---|---|---| | `-G` | no | yes | | A value written into the generator's `user.properties` | no | yes, that generator only | | A value written into the controller's `jmeter.properties` | yes | no | ## Reuse without leakage Generators normally survive many runs, so a stale value pushed by yesterday's run would be a nasty source of drift. JMeter guards against it: each engine remembers the set of keys it was given remotely, and on the next run it **removes those keys first** before applying the new set. So a key you sent with `-G` on Monday and dropped on Tuesday is genuinely gone on Tuesday, rather than lingering in the server's property map. Two limits to keep in mind: - Only keys pushed remotely are cleaned up. Anything a generator picked up from its own `user.properties` or `system.properties` files at startup stays exactly as it is. - The cleanup happens per engine, at configure time. It is not a general reset of the server's properties. ## When to reach for it `-G` is the right tool when the same plan must behave differently per run and the difference has to be visible on every generator — an environment name, a target base URL, a dataset selector. It is the wrong tool when the difference has to be *per generator*: pushing one value to four engines gives all four the same value. For that, the generators' own `user.properties` files are the lever, and JMeter reads those at server startup on each host.